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

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_*.

I see a general (and very predictable) trend of moving from imperative to declarative. Programmers like imperative, but a proper build system really prefers declarative, so CMake is trying to evolve towards declarative.

Yes, in fact, with BCM it was written like this: bcm_boost_package(core VERSION 1.61.0 DEPENDS assert config ) So its very declarative, however, using custom functions like this is discouraged. So, I am planning to at least refactor it to say: add_library(boost_core INTERFACE) bcm_boost_depends(boost_core INTERFACE boost::assert boost::config) And it can take care of calling find_package and linking. Plus, this looks more cmakey. 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.

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.

So we get "best practice" hacks like redefining find_package. I'm sorry, this doesn't feel right.

Redefining `find_package` is one way. Another way is to provide Find modules that override the behavior as well. Cmake also provides a `CMAKE_DISABLE_FIND_PACKAGE_<PackageName>` to disable certain packages, but its really only for optional dependencies. Ideally, there should be way in cmake to skip over these packages, that is to tell cmake that the package was already provided by another project in the build. For now, the easiest way, is overloading `find_package`.