Date: 2020-05-24 15:04:52
> -----Original Message-----
> From: Boost <boost-bounces_at_[hidden]> On Behalf Of Joaquin M LÃ³pez MuÃ±oz via Boost
> Sent: 23 May 2020 10:56
> To: boost_at_[hidden]
> Cc: Joaquin M LÃ³pez MuÃ±oz <joaquinlopezmunoz_at_[hidden]>
> Subject: [boost] [epochs] Proposal for an epoch-based organization of Boost libraries
> Prompted by general feelings about Boost perceived lack of modernization and internal "bloat", and
> after an explicit survey on what users dislike about Boost , I decided to try and write a more or less
> fleshed out proposal for an epoch-based organization of Boost libraries. I've extensively tested and
> refined the proposal during discussions on Reddit and the Boost Slack channel, and I feel this is now
> ready for presentation at the mailing list:
> I hope the proposal can start a productive conversation. Looking forward to your feedback.
Your epoch ideas have merit, but some disadvantages.
But I fear that (like other projects like Cmake) the BIG hurdle that we struggle to get over, is *resources*.
And particularly, resources to update *all* existing libraries in any way.
Boost does have a lot of dependencies, but they are there for excellent reasons.
Documentation is a big part of the distribution (guilty) , but are needed by most.
Tests and tests data are another area that many users rarely use, but separately them would be a big task.
It is true that Boost has become very big, but Boost is only taking up space on builder's disks, not in end-users executables.
If we could do something positive, it would be to make much clearer that nearly all Boost is header-only, and has no effect on the executables.
The Getting Started instructions have been poor from the start, and are virtually unchanged while the Boost size has increased >10-fold.
To suggest that everyone needs to build all the libraries for all the variants taking hours has become absurd when most users are only like to need a handful like system and chrono.
So we could and should *sell* Boost much better.
In conclusion, I don't think that we have the resources to do any useful split.
So while we may regret that some avoid Boost, we must resign ourselves to continue muddling through â¹
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk