Re: [boost] Proposal for moving Boost to CMake

Subject: Re: [boost] Proposal for moving Boost to CMake
From: P F (pfultz2_at_[hidden])
Date: 2017-06-18 22:06:25

> On Jun 18, 2017, at 4:33 PM, Louis Dionne via Boost <boost_at_[hidden]> wrote:
> 
>>> I intentionally left it unspecified how these files would be generated
> and 
>>> installed.
>> 
>> What is actionable in your proposal then? What is it you suggest we - by 
>> this I mean library developers, who the library guidelines target -
>> actually 
>> do? 
> 
> What's actionable is that if the Boost library requirements contain this,
> you'll have to go implement it in your own library. There you go, now we've
> taken care of all the maintained libraries. For the unmaintained ones, we
> have a community maintenance team that has commit privilege to them, and I'm
> sure we can find people to submit pull requests. Let me get the ball
> rolling; I volunteer to do the work for Boost.MPL and Boost.ConceptCheck.
> There's now 8 libraries remaining:
> 
> [ ] Boost.DateTime
> [ ] Boost.DisjointSet
> [ ] Boost.DynamicBitset
> [ ] Boost.Format
> [ ] Boost.Function
> [ ] Boost.Logic
> [ ] Boost.PropertyMap
> [ ] Boost.Signals (which is deprecated)
> [ ] Boost.Tokenizer
> [x] Boost.MPL
> [x] Boost.ConceptCheck

How are you planning to add the support? I can definitely help with this, as for most libraries it should be just massaging boostdep output to create the cmake files, but I would like to coordinate your approach.

And the next question is how do we maintain these? That is how do we tests these to make sure that they are correct for the boost release?