Boost logo

Boost :

Subject: Re: [boost] [cmake] Minimum viable cmakeification for Boost
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-06-22 17:52:17

On 6/22/2017 1:04 PM, Stefan Seefeld via Boost wrote:
> On 22.06.2017 12:04, Edward Diener via Boost wrote:
>> What I am really afraid of is not that Boost end-users do not like
>> CMake, because obviously most programmers appear to love it, but that
>> Boost will just be substituting one build system under its own
>> control, which few really understand, for another build system
>> controlled elsewhere, which more evidently understand but whose usage
>> even more people disagree about.
> Exactly. The Fact that we are having this discussion is ample
> demonstration that a move to "idiomatic" CMake is not a good idea, at
> least not for the stated reason.
> And to add that: Being among those who complained about the existing
> build system, as I'm unable to fix related issues when people file
> Boost.Python issues that are about its build logic, I'd love to move to
> a system that *I* understand and can help fix. But CMake is not that, so
> I'm not supportive of the move.
>> However if we can provide CMake for end-users from our bjam files,
>> without tortuous work, I am all for it as long as I personally don't
>> have to understand it.
> Really ? What about those end users who submit bug reports (to your
> library) originating from issues they encounter with cmake ? How will
> you support them ?

Punt ? <g>

I am assuming that any conversion of my library's bjam code to CMake
should "just work", ie. there is somne sort of conversion facility ( or
easy recipe ) from bjam to CMake that I can just run each time I make a
change to the bjam files. If that is not the case, and I am expected to
manually change CMake each time, I probably will not like such CMake
support for end-users.

> Stefan

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