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

Subject: Re: [boost] [config] 'requres' doesn't take differing -stdintoaccount
From: Peter Dimov (lists_at_[hidden])
Date: 2015-06-22 08:27:37

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-<threadapi>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.

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.

> 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?