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.
Not using import and export of targets is bad cmake, period. It doesn't scale well, causes maintenance headaches, and most importantly of all, it's trivially easy to avoid. You have two choices, low fat and high fat. Low fat is https://cmake.org/cmake/help/latest/command/export.html. I generally write a bit of cmake which extracts the targets in the default build set, and feeds them to export(TARGETS targets... NAMESPACE libname ...). This generates an exported build targets file for exactly one build configuration. This can be implemented within ten minutes. Trivially easy. High fat involves creating an install layout i.e. staging using https://cmake.org/cmake/help/latest/command/install.html install(TARGETS). You do this for each build configuration you want. You then use install(EXPORT) to generate a combined exported build targets file for many build configurations at once. This takes quite a bit more effort, I have taken days on this when converting some large projects. This is the correct way to use cmake. If you're not doing one of the above, you're doing it wrong.
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?
INTERFACE_COMPILE_OPTIONS, INTERFACE_COMPILE_DEFINITIONS. Use generator
expression $
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).
Once a cmake build group is exported, it is written in stone. That's what makes doing this scalable - the consuming build system can treat it as a black box.
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
What you're not getting here is that anything you submit which doesn't follow cmake idiomatic practice is highly likely to get rejected during review. So you're wasting your time, unless this is for personal use only.
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?
That looks about right. I was only talking to Steve last Monday in fact. He came to my talk to the Dublin C++ users group "Deterministic Disappointment". He was telling me he refuses to touch cmake ever again unless he's getting paid for it. A nasty addiction it was for him. Niall