Re: [boost] [cmake] Pull request announcement

-----Original Message----- From: Boost On Behalf Of Niall Douglas Sent: Friday, September 14, 2018 6:00 PM Cc: Niall Douglas 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