Re: [boost] [cmake] Pull request announcement

Subject: Re: [boost] [cmake] Pull request announcement
From: mike.dev_at_[hidden]
Date: 2018-09-14 16:24:35

> -----Original Message-----
> From: Boost <boost-bounces_at_[hidden]> On Behalf Of Niall Douglas
> Sent: Friday, September 14, 2018 6:00 PM
> Cc: Niall Douglas <s_sourceforge_at_[hidden]>
> Subject: Re: [boost] [cmake] Pull request announcement
> 
> > unless I'm encountering an overwhelming resistance to this idea
> > here on the ml, I intend to create a batch of PRs that introduce
> > minimal cmake support to a large subset of boost libraries
> > (maybe even all).
> 
> I would oppose this PR for the following reasons:
> 
> 1. A lot of work has been invested by many people in the Boost cmake
> implementation, which is ready for peer review. It would do its authors
> a great disservice to push through some stop gap.

It has been ready for how long now? If a real solution doesn't come for 
years and years, a stop-gap solution might be better than just hoping
for some more years for something that might never come

> 
> Instead, the OP should consider review managing the Boost cmake
> implementation if he is so keen on this. That's the blocker - lack of
> review manager. Not that the work hasn't been done.

Am I allowed to be a review manager even though I'm not a library 
maintainer? If so - sure, what do I have to do?

Proposing PRs to individual libraries seemed the only way for me as an
outsider to help with moving anything forward.

> 2. cmake is a big move for Boost. Submitting a stopgap without proper
> community review is not in keeping with Boost's established precedent
> and norms.

Afaik, every library is allowed to support any build system in addition
To b2 that it wants. So what is the problem? Contrary to BCM, I'm not
Offering a replacement for b2 - that is just beyond my capabilities
and frankly beyond the time I can spend on this.

> 3. It is the wrong stopgap solution at a technical level. The correct
> stopgap solution is an imported targets cmake file which refers to the
> build outputs generated by Boost.Build. Possibly, Boost.Build should
> generate it, but I can see worth in a Python script which can take a
> release distro and generate from that an imported targets cmake. Even
> better if said Python script can be run as part of release management,
> and the imported targets cmake file gets shipped with the release distro.

That requires a) more effort and b) only solves the consummation side. It
e.g. doesn't solve the problem of properly propagating build flags from my
cmake project to the boost libraries

> 
> I applaud the OP's eagerness. But he's proposing the wrong solution, and
> for the wrong reasons.

Sorry to hear that

> 
> Niall
> 
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost