Re: [boost] Cmake

Subject: Re: [boost] Cmake
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-06-26 21:34:03

On 26.06.2017 17:21, paul wrote:
> On Mon, 2017-06-26 at 15:46 -0400, Stefan Seefeld wrote:
>> On 26.06.2017 13:36, paul wrote:
>>> On Sun, 2017-06-25 at 13:35 -0400, Stefan Seefeld wrote:
>>>> It's precisely the lack of encapsulation that causes
>>>> this overhead. I'd be happy to include additional files in my library if
>>>> it wasn't for the implied maintenance cost.
>>> Yes, I would like the maintenance cost to be just adding source files to a
>>> list somewhere. Of course, for header-only libraries its even easier.
>>>
>>> Although, there are libraries like Boost.Python or Boost.Context that have
>>> more complicated build infrastructure, but the nice thing about cmake is
>>> that
>>> there is a much larger community to help with the maintenance cost rather
>>> than
>>> relying on a few Boost.Build gurus.
>> That's definitely true. But ultimately, it comes down to the maintainer
>> or the library's own developer community. Whenever users try to build
>> Boost.Python and run into issues, they are submitting issues to *our*
>> tracker, and I hate having to tell them to go ask for help in a
>> different community because I'm unable to help myself.
> Not exactly. The user may have a build problem, but the likeliness that
> they(or another user who is reading the issue) know enough cmake to contribute
> a fix is very much higher than them knowing enough bjam to provide a fix. 

Oh, you are arguing about bjam vs. cmake. I wasn't. (I would agree that
a well-known tool is better than an obscure one).
My point is about having to maintain (and answer questions about) two
infrastructures rather than one.

I don't think it's realistic to assume that Boost as a whole will
switch, at least not over a short period of time. If there was any
lesson to be learned from passed changes to Boost, it's that such a move
will take a very long time, if it's going to finish at all.

Therefore I think it's much better to leave the decision to switch to
individual project maintainers, as on that scale a change is much
quicker to implement, if that's what the (project-) community decides to
do.
And for that to be possible individual projects need more autonomy, and
the whole build infrastructure needs to be modular. Thus, what I propose
is a little script that iterates over all boost components, invoking
some well-defined entry-point on each, which *may* run `b2` locally, or
it may invoke `cmake`. Of course there needs to be an agreed-upon
protocol (what arguments that script needs to accept, what is the
expected outcome of a build, i.e. where are the generated artefacts,
etc.). I strongly believe that such an approach would be by far more
realistic, efficient, and generate less friction and administrative
overhead than a whole-sale move from bjam to cmake.

        Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...