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

Subject: Re: [boost] [cmake] Minimum viable cmakeification for Boost
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2017-06-20 14:42:36

Am 20.06.2017 4:21 nachm. schrieb "Peter Dimov via Boost" <
boost_at_[hidden]>:

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.

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.

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. So we get "best
practice" hacks like redefining find_package. I'm sorry, this doesn't feel
right.

I hear what you're saying. We'll end up innovating cmake, which for me
isn't a bad thing.
I'm favoring CMake due to its great support for generating for all kinds of
different environments​ (including proper visual studio solutions). To be
fair, I haven't invested as much time in boost.build as I did for cmake.
For all platforms I work on, both work equally nice with different quircks
on different ends. I'm not using an ide though. For the sake of ide
support, I'd lean towards cmake.
Regarding the discussion of what's right and wrong when writing your
CMakeLists.txt files, it's almost bike shedding. If you want to depend on a
library, you'll make it work, no matter what, that's what we do.

Nevertheless, in terms of cmakeisms, I really like what Paul put together
and what Daniel Pfeifer said in his talk makes a lot of sense in a cmake
world.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman
/listinfo.cgi/boost