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 19:25:48

Am 20.06.2017 5:08 nachm. schrieb "Niall Douglas via Boost" <
boost_at_[hidden]>:

>> Niall says that using the global BUILD_SHARED_LIBS is a cmake2ism, and
>> that explicit targets are preferred nowadays.
>
> Niall, can you point me to a reference stating this? Preferably some cmake
> documentation telling me what the right(tm) thing to do is.

Any cmake construct which requires you to write an if() in a
non-root-level CMakeLists is a cmake2-ism. There are a very few places
in cmake3 remaining where no good alternative to global variables exist.
BUILD_SHARED_LIBS is definitely not one of those.

I'll ask again: do you have any reference to those statements? The official
cmake docs seem to disagree about this specific case.

I would even call it non sensical alltogether.

Why should the root cmake be responsible for configuring a specific sub
module. This is asking for cluttering everything into one single entity in
a (almost) totally unrelated place. Why not keep it local to where it
should be used.

One concrete example: I have networking layer which supports different
transports, say tcp, libfabric, MPI and infiniband verbs. The user of my
library doesn't really care about which one is used, so ideally, I would
give him a compiled version of my library with the internal settings I
believe are best for him. In that case, my network layer module would be
configured with one of those options. Naturally, I would think, those
options are defined within this very sub project. The root project really
doesn't care, nor do I want that this implementation detail leaks into the
users CMakeLists.txt.

Would you consider that bad practice to begin with? How would you solve
this?

There are tons of other use cases very similar to that. Having everything
clobbering up in the root Cmakelists.txt doesn't sound appealing to me.

Shared libraries usually have different settings to static libs and
again to header only libs. They have different relationships to their
dependencies, different usage requirements for consumers. You can use
generator expressions to encode those differences, but then you've hard
coded them so external cmake no longer can easily override them. You
have just made your non-root CMakeLists hard to reuse by cmake you
didn't write nor design.

Generator expressions are also hard to write and debug, are
overwhelmingly confusing to read, and randomly don't work in some places
depending on which build system generator you are using. So best avoid
all of that complexity - place no complexity at all outside the
rootlevel CMakeLists. Declaration only. Place all custom logic solely in
rootlevel CMakeLists only.

> Any definite source on what a cmake2ism is or is not would be highly
> appreciated.
>
>
> 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.

I believe Stephen Kelly is negotiating a book deal on this. It'll be
some time before that book lands though.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/
mailman/listinfo.cgi/boost