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

Subject: Re: [boost] [cmake] Minimum viable cmakeification for Boost
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-06-20 15:51:40

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.

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/