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

Subject: Re: [boost] [cmake] Minimum viable cmakeification for Boost
From: paul (pfultz2_at_[hidden])
Date: 2017-06-20 17:06:09

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
> > > <boost_at_[hidden]> 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/system/
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
>