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 would recommend that check-message-compiler be modified to ignore current defines, and always return the same value. 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, Volodya