Re: [boost] Moving CMake forward

Subject: Re: [boost] Moving CMake forward
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2017-07-22 11:42:58

Le 22.07.17 à 12:51, John Maddock via Boost a écrit :
>
>> I am in. I have several things in mind, such as
>>
>> * to work on an component that describes the dependencies between
>> libraries in order to add then in a topological sort order from the
>> main project
>> * port the documentation generation, focus quickbook+doxygen at first
>> * think/design/adapt/deploy regression runners and a possibly new
>> regression dashboard
>
> All nice to have, but too advanced for me right now given that we have a
> working system for those already... the priority is to improve the end
> users experience, and keep the initial step focused enough that we can
> review it and polish it up for release without getting bogged down
> and/or acrimonious about it.

mmm... ok.

>
>>
>> How do you want to interact?
>
> To repeat, I have zero knowledge of CMake and am rather happy with what
> we have.  However, as a born-again-empiricist-scientist type I am open
> to being proved wrong.  So I'm more than happy to test whatever folks
> come up with, but maybe before even that point, I'd like to be able to
> read the equivalent of Boost's current getting started docs written for
> a CMake port of the build/install process. After that, some getting
> started docs for library authors too.  I guess that's what I'm missing
> from the current discussion - it's either too technical for me to follow
> because I'm not familiar with CMake's internals, or else too
> advocacy-based and substance free. I'm looking for something that can be
> fed to a willing guinea pig so we can see if he prospers or not ;)
>
> John.

I understand your points. I however feel like this is a bit of a 
"chicken and egg" situation: for instance, I fail to understand how one 
can write an how-to for library authors, without even having a tiny set 
of representative libraries that have proven the concept (or cmake API).

Also, it is not like you (personally) know nothing about build system. 
Even though you have no experience with cmake, you have some (even good) 
with b2, and you understand the problems those build system address. 
This makes me wonder what is the level of assumptions we can make in 
order to write a guide.

So, what I suggest is this:

1. we take one/two good developers as a target, including you for 
instance. You are the user in this case, and a group of cmake developers 
should provide you with a way to express your build requirements for a 
set of libraries of your choice. The library should not be trivial to 
port though (for instance should not be header only and should have 
other dependencies), otherwise this would be useless for most of us.
2. you review and interact with the cmake port developers, trying to 
port eg. another library with the tools that were developed in the first 
stage. If this is too complicated/difficult/error prone, then we go back 
to 1.
3. once everybody is happy (or not) we write one tentative how-to and 
report back to the ML.

On my side, I will mostly try to do what is being done with b2 for 
boost.test. (Although some people do not like it) it is a central 
library I believe, and its integration to other project will raise a lot 
of issues.

What do you think?

Raffi