On Jun 18, 2017, at 4:33 PM, Louis Dionne via Boost
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?