Re: [boost] [config] 'requres' doesn't take differing -stdintoaccount

On 6/22/2015 3:27 PM, Peter Dimov wrote:

Vladimir Prus wrote:

...

On 6/22/2015 2:41 PM, Peter Dimov wrote:

...

Vladimir Prus wrote:

...

Say, the 'link' property usually has no effect on architecture and >> address-model,

How could you know?

By examining all toolsets that support the 'link' property?

My point was that, in general, you can't know whether a property affects the address model. Maybe you can know that about "link" and other known properties, but that's not what the code does today - it doesn't eliminate known properties, it eliminates all unknown properties.

...

It is possible to solve, in general, but it requires either creating directory paths using a hash of property set (which is ugly), or storing a hash of property set is a separate data store.

When I look at project-cache.jam, I see this:

set "hardlinks supported-<abi>ms-<address-model>32-<architecture>x86-<asynch-exceptions>off-<binary-format>pe-<cxxflags>-std=c++14-<debug-store>object-<debug-symbols>on-<deduced-address-model>32-<deduced-architecture>x86-no-xsltproc-<embed-manifest>on-<exception-handling>on-<extern-c-nothrow>off-<format>html-<hardcode-dll-paths>true-<host-os>windows-<inlining>off-<install-dependencies>off-<link>shared-<location>../../..-<log-api>generic-<midl-robust>yes-<midl-stubless-proxy>yes-<optimization>off-<os>NT-<pch>on-<preserve-test-targets>on-<profiling>off-<python-debugging>off-<python>3.3-<rtti>on-<runtime-debugging>on-<runtime-link>shared-<stdlib>native-<strip>off-<suppress-import-lib>false-<symlink-location>project-relative-<target-os>windows-on-

readapi>win32-<threading>single-toolset-gcc:stdcxx14-toolset-gcc:version4.9.2-<toolset>gcc-<user-interface>console-<variant>debug-<warnings-as-errors>off-<warnings>on-<windows-api>deskto

p" : "true" ;

That is, the hardlink detection does encode cxxflags.

Even though it's independent of toolset version and C++ standard... in fact, looking at link.jam:can-hardlink, it might store all properties in config cache, but it will actually run the test only once, with whatever properties were first used - see the use of .can-hardlink variable.

But

set "Boost.Config Feature Check: cxx11_hdr_tuple-<target-os>windows-toolset-clang:version3.5.1-<toolset>clang" : "false" ;

the detection for cxx11_hdr_tuple does not.

This one has to actually compiler a source file with all relevant options, and put it somewhere, and if "relevant options" were to include cxxflags, we'd have to figure how to include cxxflags in a path or store full used path - the same problem I've mentioned in my previous email.

...

Maybe it's because it's reasonable to assume that if people adding options such as "-m32" to cxxflags know what they are doing?

You could say that.

But what then would be your recommendation? How can I have a working setup, in which I can issue

b2 toolset=gcc,gcc-cxx11,gcc-cxx14,clang,clang-cxx11,clang-cxx14,msvc-8.0,msvc-12.0

and have it properly detect that gcc by default doesn't support C++11, but does in -std=c++11 mode?

I think it's impossible to do right now, and the easiest way to support it is to make configure.build function take an additional list of properties that are relevant for this particular test, so that you can pass toolset-gcc:std in your configuration check. My naive attempt to remove filtering results in about dozen configure check results for "icu<64>" reported. alone reported, and similarly for other checks, making configure check reports quite useless. It's true that doing checks for all property sets unless a feature is positively known to have no effect is more theoretically pure, but then all other build systems will only do a single check once. - Volodya