Closed mathstuf closed 4 years ago
BoostConfig does bring in dependencies. https://github.com/boostorg/boost_install/blob/develop/test/thread/CMakeLists.txt passes, so there must be something else going on. What are the exact steps that lead to the failure?
If you're trying to use Boost::system
further down in the CMakeLists.txt
file, the problem is caused by the fact that Boost.Thread no longer indirectly depends on Boost.System via Boost.Chrono, due to this change: https://github.com/boostorg/chrono/commit/5fd1761c8395f052a7c0fe9e1143404d2dd21550
BoostConfig gets its dependency info from the Jamfiles, so if they don't declare a dependency, it won't either.
FindBoost looks at autolink instead, so it's possible for the two to get out of sync, although in this case this shouldn't be the case; Boost.Chrono should no longer autolink to Boost.System either.
Hmm. I'll have to play around in the environment I found it in. The machine is busy at the moment, but I should get time by the end of the week.
FindBoost declares a Thread dependency on System in 1.68: https://github.com/Kitware/CMake/blob/b089396f8e60c7a4a9e5fbece8484e7e77fd503a/Modules/FindBoost.cmake#L1111
and doesn't in 1.69: https://github.com/Kitware/CMake/blob/b089396f8e60c7a4a9e5fbece8484e7e77fd503a/Modules/FindBoost.cmake#L1125
Ah. This might be an issue with the third party project claiming too much and then forcing system
on me because it uses Boost::system
. I'll investigate that angle.
Similar to #18, but more tractable since it is internal dependencies only.
ends up with an "unknown target Boost::system" message. The transitive closure of the requested components should be made available to the requesting package because otherwise every package needs to embed this information internally.
FindBoost.cmake
handled the dependency tree at least, so this behavior for compatibility across the gap would be really helpful in that way too.