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

On Tue, 2017-06-20 at 16:51 +0100, Niall Douglas via Boost wrote:

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.

I am not sure who he is addressing, but what he suggest is how you should write cmake period. He never discussed any of things you are doing in his talk.

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.

Actually, a lot of what I wrote follow very closely follows to how he wrote it here: https://github.com/boost-cmake/boost-cmake/blob/master/listsfiles/libs/syste... CMakeLists.txt And this relies on `BUILD_SHARED_LIBS`.

...

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

The trend exists because this is what works for large-scale building, especially for 10000+ libraries.

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.

But what you are suggesting will be a bad neighbor. As I will not be able to build a library standalone. 

Purely declarative cmake examines no global state and so isn't affected by other people's modifications of global state.

None of my project examine global state, whereas your example does by inspecting the existenct of targets, which is 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.

Yes, and what I presented does this.

I again reiterate that nobody is stopping anyone writing their own installation logic in a rootlevel CMakeLists.

But that doesn't make the project work standalone, which is an important best practice for cmake.

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.

I don't know about most. Most places I worked at built and installed boost, even on windows.

It's painfree and works without surprises on Windows.

I have found no problems using `find_package` on windows.

It also inherits the consumer's optimisation and build settings. End users will be delighted.

I don't think so when we say you must use boost as `add_subdirectory` and if you want to use `find_package` you are own your own. A lot of cmake users want the `find_package` support.  Ultimately, we need to support both scenarios, what I presented does that. You can use it as `add_sudirectory`, you can build each project standalone, and you can use `find_package`. What you presented doesn't do those.

...

...

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,

Using `find_package` doesn't as it is up to the clients to decide how it will find the dependencies through `CMAKE_PREFIX_PATH` and `<package>_DIR` variables that can be defined by the clients.

they might have a custom build of some dependency in a custom path for example.

Yes, which is what `mylib_DIR` is for.

Niall