Peter Dimov

> That deduction is probably not appropriate for all projects That's not the question. The question is whether lack of deduction is more appropriate. Which it isn't. > (it uses...

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

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

I'm not sure how this is going to work. How are people going to use these modules? They aren't going to be shipped with the Boost.Test package as installed by...

The dependency scanner at the moment only recognizes "Boost::foo" in a line of its own, it doesn't contain a full CMake parser.

That's possible and I've had this in mind as an alternative, but it has its own issues, although on balance it may still be better than what we have now....

Oh, it also breaks one interesting case that currently works and is in use: setting BOOST_INCLUDE_LIBRARIES and BOOST_EXCLUDE_LIBRARIES to the same value of e.g. `lib`. This means, include the dependencies...

> Hm, interesting indeed. Where is this used? Here: https://github.com/boostorg/json/blob/21fcc880304c754aeb01421318e06563484c72ac/CMakeLists.txt#L42-L53

> As a slight alternative: How about using I fear that this will pick up more than we need, although it's an option if all else fails.

I'm not particularly thrilled by the prospect of having to perform proper tokenization and maintain state across lines in order to parse every possible `target_link_libraries` call. Besides, the current approach...