I'll repeat myself yet again, but to be honest it'll be for the last time as I really don't care about this enough to spend more time repeating myself. I have other stuff to be doing than repeating myself (specifically, Outcome v2).
We are not asking to repeat yourself, we are asking for references. As the references I have for best practices and modern cmake from both Daniel Pfeifer and Stephen Kelley do not align with what you are saying:
This really is the last time I'll repeat myself. After this I won't comment further as you are not listening and you keep repeating the same points after I have already explained why you are mistaken. Those references of yours regard general purpose cmake in a wide general purpose use case. In Boost's situation, we have a highly homogeneous build and configuration, plus lots of end users who do custom builds. So the use case is different. So we employ a more suitable design. Those references of yours are also slightly or very out of date. I do know Stephen personally and I know in detail where he is coming from, and where he was going with cmake3 before he paused his efforts. His own public writings and previous Boost cmake efforts are not up to date with where cmake is now at. But as I've said here previously, don't take my word for it. If Boost decides to commit to some approach, Stephen should be hired to consult on any new design. I think you'll find he greenlights my design over say your design or indeed his own previous designs because mine is closer to latest cmake best practice, and it doesn't do so much extra unnecessary stuff right now, plus it's more more future proof. But that's speculation on my part.
Yes, the build scripts should be more declarative, but projects should be standalone as well, and not require a root cmake. Of course, my approach to the boost-cmake is fairly declaritive, there is only one conditional in the top-level cmake, whereas your cmake code is much less delcarative with a lot of conditionals all over.
Nobody at any stage has said they wouldn't work standalone. Not all declared targets within would work, but some would. It's up to imperative cmake to choose which declarative cmake to use based on whatever logic it chooses. As I've already explained several times now. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/