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 Louis -- View this message in context: http://boost.2283326.n4.nabble.com/Proposal-for-moving-Boost-to-CMake-tp4695... Sent from the Boost - Dev mailing list archive at Nabble.com.