That the header exists doesn't mean it's (reasonably) usable. Boost.Config has a test for <chrono>[1]. If it passes, it may be a reason to stop defining BOOST_NO_CXX11_HDR_CHRONO on that compiler. [1]: https://github.com/boostorg/config/blob/develop/test/boost_no_cxx11_hdr_chro...

I ran the test and had no issue to compile and run it.

On 2020-05-15 20:00, Alexander Grund via Boost wrote:

Hello,

I'm trying to specify that my library uses C++11 (features) and cannot be compiled or used without.

Using `[ requires cxx11_defaulted_functions]`

I think, you missed a space before ']'.

as the project "requirements" does work (lib not build), but e.g. the tests are still build and obviously failing.

Putting the above as "usage-requirements"  (just like `<link>shared:<define>BOOST_NOWIDE_DYN_LINK=1`) doesn't have any effect.

What is the proper way to do this?

In general, requirements field designates what is required to build your library (or executable). usage-requirements designates requirements imposed on the users of your library (provided that they use Boost.Build). I'm not sure if the requires rule works in usage-requirements though, I've never used it.

...

Using `[ requires cxx11_defaulted_functions]` as the project "requirements" does work (lib not build), but e.g. the tests are still build and obviously failing.

Not sure if this what you want, but here’s an example of a test suite that skips tests if in pre-C++11:

https://github.com/boostorg/poly_collection/blob/develop/test/Jamfile.v2

Thanks, but I was wondering if I couldn't just depend on the library. I mean with this approach I have to repeat the same conditions in the tests as for the library. But that library isn't even build. So a dependency on the library sounds more reasonable and I thought that something like this must exists already

On 2020-05-16 17:50, Alexander Grund via Boost wrote:

...

https://github.com/boostorg/poly_collection/blob/develop/test/Jamfile.v2

As another note on that: I have a test to be run on windows only by using: <build>no <target-os>windows:<build>yes

This now also breaks BJam as it sees a <build>no by the C++11 requirements and a <build>yes by the above :( No idea how to solve that.

You could write a local rule that determines when to build the test. You can see an example here: https://github.com/boostorg/filesystem/blob/92522691601533a2afdec9bdecb97674... https://github.com/boostorg/filesystem/blob/92522691601533a2afdec9bdecb97674...

On 2020-05-18 11:43, Alexander Grund via Boost wrote:

...

...

As another note on that: I have a test to be run on windows only by using: <build>no <target-os>windows:<build>yes

This now also breaks BJam as it sees a <build>no by the C++11 requirements and a <build>yes by the above :( No idea how to solve that.

You could write a local rule that determines when to build the test. You can see an example here:

https://github.com/boostorg/filesystem/blob/92522691601533a2afdec9bdecb97674...

https://github.com/boostorg/filesystem/blob/92522691601533a2afdec9bdecb97674...

This will get ugly here. I have 1 test which must only be build on Windows. ALL tests must only be build in C++11.

Hence I would need to decorate _every_ test with the C++11 requirement but that 1 test where I need to define a function that checks for the C++11 requirement _and_ if it is on Windows.

The requirements specified for the project are applied to all targets in the Jamfile. So you can apply the C++11 requirement to the project and the Windows requirement to that one test.

I guess this could be solved if B2 allows negation. So I can say: `<target-os>not windows:<build>no `. Does this exist?

I'm not aware of such; I don't think it is supported other than through the <conditional> rule.

On 2020-05-18 13:16, Alexander Grund via Boost wrote:

...

...

...

...

As another note on that: I have a test to be run on windows only by using: <build>no <target-os>windows:<build>yes

This now also breaks BJam as it sees a <build>no by the C++11 requirements and a <build>yes by the above :( No idea how to solve that.

This will get ugly here. I have 1 test which must only be build on Windows. ALL tests must only be build in C++11.

Hence I would need to decorate _every_ test with the C++11 requirement but that 1 test where I need to define a function that checks for the C++11 requirement _and_ if it is on Windows.

The requirements specified for the project are applied to all targets in the Jamfile. So you can apply the C++11 requirement to the project and the Windows requirement to that one test. This is what I'm already doing, see above. The problem is that the project-wide C++11 requirement yields <build>no while the windows requirement yields <build>yes which causes a conflict and a hard error in B2:

https://ci.appveyor.com/project/Flamefire/nowide-fr98b/builds/32945388/job/1...

The relevant line is this: https://github.com/boostorg/nowide/blob/755dbe5255211677eebbe0a3795e44b1afb3...

The problem is that you have <build>no and <build>yes at the same time on Windows. The conditional rule I suggested would produce no additional properties on Windows (so that the test builds, provided that it is not disabled by other requirements) and <build>no on other target systems. rule check-windows ( properties * ) { local result ; if ! <target-os>windows in $(properties) { result = <build>no ; } return $(result) ; }