|
Boost Users : |
Subject: Re: [Boost-users] boost 1.47: gcc file dependency generation trips over BOOST_PARAMETER_MAX_ARITY
From: Ytsen de Boer (yrdeboer_at_[hidden])
Date: 2011-09-15 05:09:03
Thank you for your answer.
I believe we are not on the same page.
Obviously, when I define the max arity to a value of 7 or more, the
preprocessor will finish properly.
But the point I am trying to make is more subtle, namely, that the
generation of the project dependencies has not a thing to do with the
boost max arity. Therefore, the definition of that macro would be
terribly misplaced in the make rule for the dependencies, which has
only to do with the dependent files and nothing with the numeric
values of macros. At least, that is how it should be in my opinion.
I don't know what the boost max arity means or what its for, but it
seems to me that it is a run time variable. As such, it should be
handled by the code and not by preprocessor directives, surely not
with this side-effect. I hope this can be acknowledged.
Kind regards,
Ytsen.
2011/9/15 Ivan Le Lann <ivan.lelann_at_[hidden]>:
>
> ----- "Ytsen de Boer" <yrdeboer_at_[hidden]> a écrit :
>
>> Thank you for your response, please allow me to explain the problem
>> a bit clearer:
>>
> (removed -MM explanation)
>
> I believe this has nothing to do with -MM.
> Does your code compile without dependency generation ?
>
> Obviously Boost.Signals2 needs this macro to be at least 7.
> You probably include another boost library before Signals2 that default it to less than 7.
>
> See:
> http://boost.2283326.n4.nabble.com/Accumulators-Signals2-Compilation-error-with-GCC-when-both-are-used-td3585468.html
> I think you should define this macro (to 7 or more) in your compiler command.
>
> Regards,
> Ivan
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net