b2
b2 copied to clipboard
bfgroup
Compiling with clang-linux-11.0 on Windows
When I test a "Boost" library with clang-linux-11.0 targeting gcc in c11 mode on Windows I see:
`Performing configuration checks
- default address-model : 64-bit (cached) [1]
- default architecture : x86 (cached) [1]
- BOOST_COMP_GNUC >= 4.7.4 : no (cached) [2]
- BOOST_COMP_GNUC >= 4.3.0 : no (cached) [2]
- BOOST_COMP_GNUC >= 4.7.4 : no (cached) [3]
- BOOST_COMP_GNUC >= 4.3.0 : no (cached) [3]
- symlinks supported : yes (cached)
[1] clang-11.0 [2] clang-linux-c11-11.0/debug/address-model-64/python-2.7/threadapi-pthread/threading-multi/visibility-hidden [3] clang-linux-c11-11.0/debug/python-2.7/threadapi-win32/threading-multi/visibility-hidden`
What do the [1], [2], and [3] notations come from ? Because something appears wrong that both the 'pthread' and 'win32' threading models are being used, and I want to get to the bottom of why this is so. I am not specifying myself any thread api in my clang-linux-11.0 toolset.
Last time this came up it was in a discussion with @pdimov on slack (https://cpplang.slack.com/archives/C27KZLB0X/p1612881729331900). And we didn't get to the bottom of it. For information..The "[n]" notation comes from new diagnostic code I put in to identify the variant context that configure checks run with as it's now variable based on the feature set requested. It means something is requesting those checks for both threadapi=pthread and threadapi=win32. The likeliest avenue for that is a test is depending, likely indirectly, on Boost.Thread which has build code that specifies both of those as requirements.
Unfortunately since I am not a member of cpplang.slack I can not view the archives. If I step through the Boost Build code in clang-linux.jam with the debugger, where should I be looking to see what is happening ?
What we discovered was that the same configuration checks (on Windows), when executed from a library's build/Jamfile, did not test threadapi-pthread, but only threadapi-win32. However, when executed from test/Jamfile, they were performed for threadapi-pthread as well. This is where I abandoned it; I have no idea where to look and no theory as to why testing would have this effect.
What is meant by "configuration checks" and how is this related to what is in a jamfile ? In my case I understand the threadapi-pthread, since I am using clang-linux-11.0 as the compiler, which is clang targeting gcc on Windows. But am I also picking up a threadapi-win32 because some Boost library, which the library I am testing depends upon, is using the Windows threadapi in its code ? I am using the Boost.Test library rather than the lightweight test library, mainly because I want to test double closeness, so maybe Boost.Test uses the Windows threadapi on Windows even when the compiler is clang-linux using the mingw-w64 gcc backend.
In your case the configuration checks are BOOST_COMP_GNUC >= 4.7.4 : no (cached) and BOOST_COMP_GNUC >= 4.3.0 : no (cached). I don't think this is caused by Boost.Test, because I was seeing the problem when testing Mp11, and it doesn't use Boost.Test.
Those checks come from:
[ predef-check "BOOST_COMP_GNUC >= 4.7.4" : : <cxxflags>-ftrack-macro-expansion=0 ]
[ predef-check "BOOST_COMP_GNUC >= 4.3.0" : : <cxxflags>-Wno-variadic-macros ]
Why would those checks generate two different threadapis ? I only specify them once in the jamfile for the tests I run ? The library I am testing is header-only.
The likeliest avenue for that is a test is depending, likely indirectly, on Boost.Thread which has build code that specifies both of those as requirements.
No, it is a pure b2 issue. I scratched my head over it a while ago, with no Boost involved at all and Jamroot with content of:
obj asd : asd.cpp ;
explicit asd ;
obj main : main.cpp : [ check-target-builds asd ] ;
b2 produces:
Performing configuration checks
- asd builds : yes [1]
- asd builds : yes [2]
[1] msvc-14.2/debug/threadapi-pthread
[2] msvc-14.2/debug/threadapi-win32
...found 3 targets...
...updating 1 target...
compile-c-c++ bin\msvc-14.2\debug\main.obj
main.cpp
...updated 1 target...
with backtrace
in configure.jam add to check-target-builds-worker::check
ECHO "check-target-builds-worker::check(" ;
for local p in $(properties) { ECHO " $(p)" ; }
ECHO ")" ;
local bt = [ BACKTRACE ] ;
while $(bt) {
ECHO "$(bt[1]):$(bt[2]) |" $(bt[4]) "|" $(bt[3]) ;
bt = $(bt[5-]) ;
}
check-target-builds-worker::check(
<asynch-exceptions>off
<coverage>off
<debug-store>object
<debug-symbols>on
<embed-manifest-via>mt
<embed-manifest>on
<exception-handling>on
<extern-c-nothrow>off
<hardcode-dll-paths>true
<host-os>windows
<inlining>off
<install-dependencies>off
<link>shared
<midl-robust>yes
<midl-stubless-proxy>yes
<optimization>off
<os>NT
<pch>on
<preserve-test-targets>on
<profiling>off
<response-file>auto
<rtti>on
<runtime-debugging>on
<runtime-link>shared
<stdlib>native
<strip>off
<suppress-import-lib>false
<symlink-location>project-relative
<target-os>windows
<testing.execute>on
<threadapi>pthread
<threading>single
<toolset-msvc:version>14.2
<toolset>msvc
<user-interface>console
<variant>debug
<vectorize>off
<warnings-as-errors>off
<warnings>on
<windows-api>desktop
)
C:/Tools/b2/src/build\configure.jam:515 | check | object(check-target-builds-worker)@98.
C:/Tools/b2/src/kernel\modules.jam:107 | modules.call-in | object(check-target-builds-worker)@98.
C:/Tools/b2/src/util\indirect.jam:105 | indirect.call | indirect.
C:/Tools/b2/src/build\property.jam:132 | property.evaluate-conditionals-in-context | property.
C:/Tools/b2/src/build\targets.jam:1088 | evaluate-requirements | targets.
C:/Tools/b2/src/build\targets.jam:1122 | common-properties2 | targets.
C:/Tools/b2/src/build\targets.jam:1018 | targets.common-properties | targets.
C:/Tools/b2/src/build\targets.jam:1314 | [email protected] | object(typed-target)@100.
C:/Tools/b2/src/build\targets.jam:812 | generate-really | object(main-target)@172.
C:/Tools/b2/src/build\targets.jam:784 | [email protected] | object(main-target)@172.
C:/Tools/b2/src/build\targets.jam:273 | [email protected] | object(project-target)@96.
C:/Tools/b2/src\build-system.jam:797 | load | build-system.
C:/Tools/b2/src/kernel\modules.jam:295 | import | modules.
C:/Tools/b2/src/kernel/bootstrap.jam:139 | boost-build |
G:/zxczxc/boost-build.jam:1 | module scope |
Performing configuration checks
- asd builds : yes [1]
check-target-builds-worker::check(
<asynch-exceptions>off
<coverage>off
<debug-store>object
<debug-symbols>on
<embed-manifest-via>linker
<embed-manifest>on
<exception-handling>on
<extern-c-nothrow>off
<hardcode-dll-paths>true
<host-os>windows
<inlining>off
<install-dependencies>off
<link>shared
<midl-robust>yes
<midl-stubless-proxy>yes
<optimization>off
<os>NT
<pch>on
<preserve-test-targets>on
<profiling>off
<response-file>auto
<rtti>on
<runtime-debugging>on
<runtime-link>shared
<stdlib>native
<strip>off
<suppress-import-lib>false
<symlink-location>project-relative
<target-os>windows
<testing.execute>on
<threadapi>win32
<threading>single
<toolset-msvc:version>14.2
<toolset>msvc
<user-interface>console
<variant>debug
<vectorize>off
<warnings-as-errors>off
<warnings>on
<windows-api>desktop
)
C:/Tools/b2/src/build\configure.jam:515 | check | object(check-target-builds-worker)@98.
C:/Tools/b2/src/kernel\modules.jam:107 | modules.call-in | object(check-target-builds-worker)@98.
C:/Tools/b2/src/util\indirect.jam:105 | indirect.call | indirect.
C:/Tools/b2/src/build\property.jam:132 | property.evaluate-conditionals-in-context | property.
C:/Tools/b2/src/build\targets.jam:1088 | evaluate-requirements | targets.
C:/Tools/b2/src/build\targets.jam:1122 | common-properties2 | targets.
C:/Tools/b2/src/build\targets.jam:1018 | targets.common-properties | targets.
C:/Tools/b2/src/build\targets.jam:1314 | [email protected] | object(typed-target)@100.
C:/Tools/b2/src/build\targets.jam:812 | generate-really | object(main-target)@172.
C:/Tools/b2/src/build\targets.jam:784 | [email protected] | object(main-target)@172.
C:/Tools/b2/src/build\targets.jam:273 | [email protected] | object(project-target)@96.
C:/Tools/b2/src\build-system.jam:797 | load | build-system.
C:/Tools/b2/src/kernel\modules.jam:295 | import | modules.
C:/Tools/b2/src/kernel/bootstrap.jam:139 | boost-build |
G:/zxczxc/boost-build.jam:1 | module scope |
- asd builds : yes [2]
[1] msvc-14.2/debug/threadapi-pthread
[2] msvc-14.2/debug/threadapi-win32
...found 3 targets...
...updating 1 target...
compile-c-c++ bin\msvc-14.2\debug\main.obj
main.cpp
...updated 1 target...
A place where asd target builds twice is https://github.com/bfgroup/b2/blob/b4e1a65a392b663ca35e786f7a7a4ebbdca94128/src/build/targets.jam#L769-L793
generate called there for asd with property-set of:
-
[ <threadapi>pthread <toolset-msvc:version>14.2 <toolset>msvc <variant>debug ] -
[ <threadapi>win32 <toolset-msvc:version>14.2 <toolset>msvc <variant>debug ]
and I have no idea why it is done that way.
I am pretty much sure that evaluate-requirements needs a fix. https://github.com/bfgroup/b2/blob/b4e1a65a392b663ca35e786f7a7a4ebbdca94128/src/build/targets.jam#L1024-L1117
It currently evaluates conditionals in semi-parallel rounds, and the result of that: toolset defaults are evaluated in parallel with other conditionals.