Re: [boost] [cmake] Minimum viable cmakeification for Boost

On 20/06/2017 15:55, P F via Boost wrote:

...

On Jun 20, 2017, at 9:20 AM, Peter Dimov via Boost wrote:

Thomas Heller wrote:

...

As a general observation, I see a lot of statements along the lines of "I state that XYZ is preferable over UVW", it would be nice to have to have background information (pros and cons anyone? what do the cmake authors/docs have to say about this?) on those statements so that everyone can form their own opinion instead of having to choose whom to trust about what's "standard" cmake.

That's the problem with CMake, there's no way for someone like me who does not follow it to get a definitive answer to what idiomatic CMake 3.5+ is. There are several articles about it, they all say more or less the same thing - use target_*. I get that. But that's not enough.

But Daniel Pfeifer’s presentations go over more than use target_*.

He was also addressing an audience with existing legacy cmake systems. If you are in the very fortunate position of starting from a completely clean sheet like we are, you'd do differently. You know you could just drop Daniel a line and ask for a bit of his time. He used to be on boost-dev, indeed he and I and Dave worked on the git conversion.

Although, I think the trend with cmake is moving away from subproject builds and towards standalone builds. This is why it supports exporting its targets so it can be consumed after installation.

That trend exists only because so much existing cmake is a very bad neighbour to other cmake, so you need to ring fence cmake-innovations away from one another as they trample on one another. Purely declarative cmake examines no global state and so isn't affected by other people's modifications of global state. It also changes no global state, so it is always a good neighbour. Therefore, unlike most existing cmake, it is always safe to use in subproject builds. I again reiterate that nobody is stopping anyone writing their own installation logic in a rootlevel CMakeLists. You can go ahead and implement target export and anything else you like on your own if that's what suits you. But most will simply do subproject builds. It's painfree and works without surprises on Windows. It also inherits the consumer's optimisation and build settings. End users will be delighted.

...

Take for example find_package. It's a command, find me this package, now. But it's much better if a library does not issue "find me this package" commands, but rather declares which packages it needs.

A library may want to compile differently if a dependency isn't there, or even use completly different set of dependencies, which is best expressed imperatively the declaratively.

You declare alternative targets for those situations and leave the rootlevel CMakeLists decide what is wanted. Non-rootlevel CMakeLists cannot be enforcing choices of how to best detect presence of dependencies on end users, they might have a custom build of some dependency in a custom path for example. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/