[boost] [cmake] Pull request announcement

Subject: [boost] [cmake] Pull request announcement
From: mike.dev_at_[hidden]
Date: 2018-09-18 21:51:32

> -----Original Message-----
> From: Boost <boost-bounces_at_[hidden]> 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