Boost logo

Boost :

Subject: [boost] [cmake] Pull request announcement
From: mike.dev_at_[hidden]
Date: 2018-09-15 15:32:57

> -----Original Message-----
> From: Boost <boost-bounces_at_[hidden]> On Behalf Of Bjorn Reese via Boost
> Sent: Saturday, September 15, 2018 2:11 PM
> To: Mike Dev via Boost <boost_at_[hidden]>
> Cc: Bjorn Reese <breese_at_[hidden]>
> Subject: Re: [boost] [cmake] Pull request announcement
> On 09/14/18 13:44, Mike Dev via Boost wrote:
> > This will not address
> > - Testing
> [...]
> > In short: all the difficult stuff is left out ;)
> > The goal is not to present a solution that can replace b2 but to have
> > a minimal starting point upon which individual library authors or the
> > community as a whole can make iterative improvements. If and when BCM
> > (or an alternative) is accepted into boost, individual libraries can
> > then easily switch to this full-fledged solution and of course any
> > author can create a more complete CMake solution for his library at
> > any time (as some already have).
> In my experience, we want to have both an integration and standalone
> CMake file. This split is necessary to avoid problems with multiple
> instances of enable_testing() when using one library from another.
> * The integration file builds only what is necessary for integration
> into other projects. This is similar to what you are proposing.
> * The standalone file builds everything including test and
> documentation. This reuses the integration file to build the library
> itself.
> If we place your proposed CMake file in the library root, and dependent
> libraries start using that location, then it becomes difficult to later
> have the standalone CMake file in the library root, which is the more
> natural choice. So we should be cautious about where we place these
> files.

Could you elaborate, why this would require separate/conflicting
cmake files as opposed to having multiple different targets in a
single file?

More to the point: Anything related to testing should reside in a cmake
file inside the "tests" folder, which is called from the cmake
file at the root, but that is mainly a matter of properly structuring the
cmake code - just as you usually don't put all your code into a single
header file, even if it might end up in a single translation unit in the end.
The same is true for docs.

In particular: Just because a cmake file is processed doesn't mean any
of the targets it contains have to be build automatically.

If you have genuine concerns however, I'm happy to further discuss
them in detail. I certainly don't want to do anything that will prevent
a future full-fledged cmake version.

Boost list run by bdawes at, gregod at, cpdaniel at, john at