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-21 02:14:43

>> I'll repeat myself yet again, but to be honest it'll be for the last
>> time as I really don't care about this enough to spend more time
>> repeating myself. I have other stuff to be doing than repeating myself
>> (specifically, Outcome v2).
> 
> We are not asking to repeat yourself, we are asking for references. As the
> references I have for best practices and modern cmake from both Daniel Pfeifer
> and Stephen Kelley do not align with what you are saying:

This really is the last time I'll repeat myself. After this I won't
comment further as you are not listening and you keep repeating the same
points after I have already explained why you are mistaken.

Those references of yours regard general purpose cmake in a wide general
purpose use case. In Boost's situation, we have a highly homogeneous
build and configuration, plus lots of end users who do custom builds. So
the use case is different. So we employ a more suitable design.

Those references of yours are also slightly or very out of date. I do
know Stephen personally and I know in detail where he is coming from,
and where he was going with cmake3 before he paused his efforts. His own
public writings and previous Boost cmake efforts are not up to date with
where cmake is now at.

But as I've said here previously, don't take my word for it. If Boost
decides to commit to some approach, Stephen should be hired to consult
on any new design. I think you'll find he greenlights my design over say
your design or indeed his own previous designs because mine is closer to
latest cmake best practice, and it doesn't do so much extra unnecessary
stuff right now, plus it's more more future proof. But that's
speculation on my part.

> Yes, the build scripts should be more declarative, but projects should be
> standalone as well, and not require a root cmake. Of course, my approach to
> the boost-cmake is fairly declaritive, there is only one conditional in the
> top-level cmake, whereas your cmake code is much less delcarative with a lot
> of conditionals all over. 

Nobody at any stage has said they wouldn't work standalone. Not all
declared targets within would work, but some would. It's up to
imperative cmake to choose which declarative cmake to use based on
whatever logic it chooses. As I've already explained several times now.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/