[log][regression] Error with Boost.Lob build jamfile breaks MinGW regression tester in develop
Hi, My develop branch regression runner fails whereas the master one works fine. The develop runner fails with all Mingw targets (msvc 7.1 works fine), with this error: ************************************ # Starting tests ("c:\boost\develop\boost_bb\src\engine\bin.ntx86\bjam.exe" "-sBOOST_BUILD_PATH=c:\boost\develop;c:\boost\develop\boost_bb\src" "-sBOOST_ROOT=c:\boost\develop\boost_root" "--boost=c:\boost\develop\boost_root" "--boost-root=c:\boost\develop\boost_root" "--boost-build=c:\boost\develop\boost_bb\src" "--debug-configuration" -l300 toolset=gcc-6.1c++14 -d2 preserve-test-targets=off --dump-tests -j3 --abbreviate-paths debug-symbols=off -m64 "--build-dir=c:\boost\develop\results"
"c:\boost\develop\results\bjam.log" 2>&1)...
c:\boost\develop\boost_root\status>
"c:\boost\develop\boost_bb\src\engine\bin.ntx86\bjam.exe"
"-sBOOST_BUILD_PATH=c:\boost\develop;c:\boost\develop\boost_bb\src"
"-sBOOST_ROOT=c:\boost\develop\boost_root"
"--boost=c:\boost\develop\boost_root"
"--boost-root=c:\boost\develop\boost_root"
"--boost-build=c:\boost\develop\boost_bb\src"
"--debug-configuration"
-l300
toolset=gcc-6.1c++14
-d2 preserve-test-targets=off --dump-tests -j3
--abbreviate-paths debug-symbols=off -m64
"--build-dir=c:\boost\develop\results"
1>>"c:\boost\develop\results\bjam.log" 2>&1
# Running Boost.Build tests
Traceback (most recent call last):
File "run.py", line 71, in <module>
runner(root)
File "c:\boost\develop\boost_regression_src\regression.py", line
287, in __init__
self.main()
File "c:\boost\develop\boost_regression_src\regression.py", line
624, in main
getattr(self,action_m)()
File "c:\boost\develop\boost_regression_src\regression.py", line
589, in command_regression
self.command_test()
File "c:\boost\develop\boost_regression_src\regression.py", line
368, in command_test
self.command_test_boost_build()
File "c:\boost\develop\boost_regression_src\regression.py", line
410, in command_test_boost_build
"boost/bin.v2/libs/any/test/any_test.test"));
WindowsError: [Error 3] The system cannot find the path specified:
'c:\\boost\\develop\\results\\boost/bin.v2/libs/any/test/any_test.test/*.*'
************************************
That path ("..libs/any/test/any_test.test/) is hardcoded in
regression.py, but it's not generated in my bin.v2 so it's reasonable an
error saying that the system can't find the path ;-)
It seems that error occurs before boost.build tests, as bjam.log shows:
************************************
C:/boost/develop/boost_bb/src/build\targets.jam:1077: in
evaluate-requirements from module targets
error: Can not evaluate conditional properties
<conditional>@Jamfile
On July 9, 2016 12:53:54 PM Ion Gaztañaga
Hi,
My develop branch regression runner fails whereas the master one works fine.
It seems that error occurs before boost.build tests, as bjam.log shows:
************************************
C:/boost/develop/boost_bb/src/build\targets.jam:1077: in evaluate-requirements from module targets error: Can not evaluate conditional properties
I'm away for the weekend, so I won't be very helpful until tomorrow night or next week. I don't have access to a Windows machine right now and it builds on my Linux fine. Right now I can tell that this is something new as I did not commit to Boost.Log for quite a while. Maybe something in Boost.Build changed for MinGW? It looks like it might be related to the <conditional> requirements in the project. Can you try commenting these lines in log/build/Jamfile.v2 individually?
On 09/07/2016 17:13, Andrey Semashev wrote:
It looks like it might be related to the <conditional> requirements in the project. Can you try commenting these lines in log/build/Jamfile.v2 individually?
Good catch. I've commented code and found the error is in the function rule check-message-compiler ( properties * ) I've changed the line 117: if <target-os>windows in $(properties) to if <target-os>windows in $(properties) && !<toolset>gcc in $(properties) and the error goes away. It seems that the line 121: local has_mc = \ [ configure.builds (...) : $(properties) : message-compiler ] ; is where the problem lies. The Boost.log documentation states that "at some point the library will require a Message Compiler tool (mc.exe), which is not available in MinGW, Cygwin and some versions of MSVC Express Edition". The check seems to hurt Boost.Build when using a MINGW environment. I don't know if my change makes any sense as windows supports many compilers (clang, intel, borland, ) so maybe the "if" condition should be more complex. I've applied the change locally and regression tests are up again. Best, Ion
On July 9, 2016 6:55:10 PM Ion Gaztañaga
On 09/07/2016 17:13, Andrey Semashev wrote:
It looks like it might be related to the <conditional> requirements in the project. Can you try commenting these lines in log/build/Jamfile.v2 individually?
Good catch. I've commented code and found the error is in the function
rule check-message-compiler ( properties * )
I've changed the line 117:
if <target-os>windows in $(properties)
to
if <target-os>windows in $(properties) && !<toolset>gcc in $(properties)
and the error goes away. It seems that the line 121:
local has_mc = \ [ configure.builds (...) : $(properties) : message-compiler ] ;
is where the problem lies.
The Boost.log documentation states that "at some point the library will require a Message Compiler tool (mc.exe), which is not available in MinGW, Cygwin and some versions of MSVC Express Edition". The check seems to hurt Boost.Build when using a MINGW environment.
I don't know if my change makes any sense as windows supports many compilers (clang, intel, borland, ) so maybe the "if" condition should be more complex. I've applied the change locally and regression tests are up again.
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. For now you can also try building with define=BOOST_LOG_WITHOUT_EVENT_LOG in b2 command line. This should save you from having to modify the vanilla Jamfile.
On 09/07/2016 18:21, Andrey Semashev wrote:
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.
Ok, I didn't know whether configure.builds /boost/log/message-compiler//test-availability : $(properties) : message-compiler was handled by Boost.Build or it was something local to your Boost.Log Jamfile. CC'ing Vladimir in case he can figure out how can this be properly fixed in Boost.Build. Best, Ion
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
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.
On 07/12/16 23:06, Andrey Semashev wrote:
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.
It didn't fix the problem. I've added a workaround though: return <define>BOOST_LOG_WITHOUT_EVENT_LOG from check-message-compiler even if it is already present in properties. This way it works on my system. I noticed that currently there are two similar lines like - message-compiler: ... during the configuration process while before there was only one.
On 12/07/2016 23:33, Andrey Semashev wrote:
On 07/12/16 23:06, Andrey Semashev wrote:
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.
It didn't fix the problem.
I've added a workaround though: return <define>BOOST_LOG_WITHOUT_EVENT_LOG from check-message-compiler even if it is already present in properties. This way it works on my system.
I noticed that currently there are two similar lines like
- message-compiler: ...
during the configuration process while before there was only one.
Great. I've checked current develop head the problem is gone. Thanks Vladimir and Andrey! Ion
participants (3)
-
Andrey Semashev -
Ion Gaztañaga -
Vladimir Prus