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