Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk