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

Subject: Re: [boost] [config] 'requres' doesn't take differing -stdintoaccount
From: Vladimir Prus (vladimir.prus_at_[hidden])
Date: 2015-06-22 14:22:46

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-<doxygen.doxproc.index>no-<doxygen.processor>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-<testing.execute>on-<th
>
> readapi>win32-<threading>single-<toolset-gcc:std>cxx14-<toolset-gcc:version>4.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:version>3.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