Boost logo

Boost :

Subject: Re: [boost] Cmake
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-06-25 20:07:23

>> Ok, my wording wasn't clear: "the lack of disambiguation to cmake of
>> header, static and shared libraries unfortunate"
> Yes, as much as I like - in principle - the separate ::static/::shared
> targets, they are an "innovation" that raises certain questions to which
> I don't have satisfactory answers, so I felt that the initial
> cmake-ification should not innovate in this area.

They are definitely not an innovation. That target-based, fully
declarative cmake programming was always the end goal of cmake 3. If you
read the discussions on cmake-dev that was always clear.

Now, I'll grant you that the choice to eliminate as much detail as
possible from nonroot CMakeLists is unusual, and could be called an
"innovation". However as anyone who has been dropped into mature
corporate cmake knows, rootlevel reprogramming of child cmake is both
very common and very well understood (search for all cmake stackoverflow
posts by my former work colleague Fraser, he taught me most of my low
level cmake tricks. Lovely guy too, he lurked here on boost-dev for many
years, I don't believe he ever posted).

Most would consider rootlevel reprogramming an anti-pattern to be
avoided, and normally when you are overriding hard coded decisions in
child cmake then it is. But if the child cmake never hard coded anything
it didn't have to, suddenly it becomes a powerful form of abstraction
and reusability. Well, powerful for cmake at least.

But as I've said many times now, whomever ends up implementing this will
decide, so much if not most of this discussion is moot and it always
was. The real question is who will be implementing this and how far it
will be taken within what time frame, and until the proposal lands at
the SC and they take a decision, I'm not sure if further bike shedding
here is worth anybody's time.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at