From: Joaquin M LÃ³pez MuÃ±oz (joaquinlopezmunoz_at_[hidden])
Date: 2020-05-24 16:52:51
El 24/05/2020 a las 17:04, Paul A Bristow via Boost escribiÃ³:
> 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.
I agree with much of what you say here, in particular with your
Boost has a PR problem.
Most Boost libs are indeed header-only, which dispenses many users with the
need of building. But even in this case one has to drag a lot of
Users are comparing Boost (fairly or not) with header-only libs without any
> 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 â¹
I'd say at least phases 0 and 1 of the proposed plan for this:
are fairly economical in terms of needed effort. Once put in place,
of course depend on how this actually incentivizes authors to do their
JoaquÃn M LÃ³pez MuÃ±oz
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk