Subject: Re: [boost] [log][regression] Error with Boost.Lob build jamfile breaks MinGW regression tester in develop
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2016-07-12 16:06:20
On 07/12/16 22:38, Vladimir Prus wrote:
> On 09-Jul-16 7:21 PM, Andrey Semashev wrote:
>> There are multiple message compilers on Windows. MinGW ships windmc,
>> IIRC. It can also work with mc from MSVC if one is found. So disabling
>> it based on the C++ compiler is not quite correct.
>>
>> The whole point of this <conditional> stuff is to detect if there's any
>> way to build .mc files, and I would really prefer if Boost.Build handled
>> that. I think, unless I'm doing something terribly wrong, Boost.Build
>> should be fixed.
>
> Although Boost.Build can possible tell whether .mc files can be handled
> - without writing a full-blown configuration test - I think the
> immediately faulty code is check-message-compiler. What is has is:
>
> if ! [ has-config-flag BOOST_LOG_WITHOUT_EVENT_LOG : $(properties) ]
> {
> local has_mc = ...
> if ! $(has_mc)
> {
> result += <define>BOOST_LOG_WITHOUT_EVENT_LOG ;
>
>
> The algorithm Boost.Build uses to determine final properties for a
> metatarget is iterative - all conditionals and indirect conditionals
> are applied until we reach a fixed point.
>
> Say, the function above determines there's no mc, and sets
> <define>BOOST_LOG_WITHOUT_EVENT_LOG. On the next iteration of the loop,
> the function is called again and has-config-flag does this:
>
> if ( <define>$(flag) in $(properties) ...
> {
> return 1 ;
> }
>
> and sees <define>BOOST_LOG_WITHOUT_EVENT_LOG, therefore
> check-message-compiler returns nothing, and on next iteration it is
> called without
> the define, and add it again. After a few iteration, Boost.Build decides
> that the process does not converge, and gives up.
I'm not sure I understand. has-config-flag checks for
<define>BOOST_LOG_WITHOUT_EVENT_LOG in properties and if it finds it
then it's already there. Why should check-message-compiler add it again
in this case? Isn't the resulting set of properties the same either way?
> I would recommend that check-message-compiler be modified to ignore
> current defines, and always return the same value.
BOOST_LOG_WITHOUT_EVENT_LOG can be specified by user, and it should have
effect of disabling everything related to event log, including message
compiler detection.
> In the meantime, I'll see whether a more convenient way of implemeting
> 'has_mc' above can be added - but check-message-compiler still will
> have to be fixed.
Thanks.
I'm embarrassed to say that I just noticed the check-message-compiler
rule didn't have a return statement at all. Not sure how it worked
before. Maybe that's what was causing the problem? I've added it now.