-----Original Message----- From: Boost
On Behalf Of Niall Douglas via Boost Sent: Tuesday, September 18, 2018 7:44 PM It is very sad that cmake doesn't (AFAIK) support directory scoped target names.
It's unnecessary if you're using cmake right.
I've stopped trying to discern, what is the "right way" to use cmake, but I'm Sure it doesn't hurt to be robust against a common way to use cmake.
Conditional activation is not ideal either, because at some point someone probably wants to build all of boost and run all the tests together (e.g. release / integration tests).
In which case have cmake execute cmake as a custom build command to build the ctest database, and then run ctest separately.
Prefixing everything with boost_<lib>_<target> is probably the cleanest solution but annoying to type.
Not sure if there is a better solution
The cmake idiomatic solution is to export those cmake targets from each library which can be externally consumed, during which you can prefix them with a namespace.
Doing it that way, Is there an easy way to ensure the same compiler flags and definitions are used for all compilations? Or the reverse: Is there a way to communicate the available options from the sub-libraries to the super-project (e.g. for use in ccmake)? So far I've only used this style with bigger groups of applications/frameworks not on a per-library basis (especially with a tightly coupled group of libraries like boost). Anyway, this is precisely the reason, why my PRs try to stay clear of anything more advanced than simple target declaration, static builds and dependency information: Too many possibilities and opinions. This is something I'm happy to leave to the cmake professionals and the boost review process
Stephen Kelly outlined all this on here many years ago. And he would certainly know. Search the boost-dev archives.
Could you be a bit more specific? There is a lot of cmake related discussion in the archives. Was that part of this thread: https://lists.boost.org/boost-build/2016/05/28637.php?
Niall
Mike