[boost] [cmake] Pull request announcement

-----Original Message----- From: Boost On Behalf Of Bjorn Reese via Boost Sent: Saturday, September 15, 2018 2:11 PM To: Mike Dev via Boost Cc: Bjorn Reese 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.