Ruben Perez via Boost
1. Dependency management. There is a place where I've had to list my indirect dependencies. Depinst takes a lot of time to run. Depending on OpenSSL is a pain. If we're to attract any young devs, we can't say "uf, a dependency, that's going to be a problem".
2. Bjam. I love B2, I think it's much better than CMake in a lot of things. But the language doesn't help. The same set of concepts, but exposed in a modern scripted language (say Python, Starlark, JS) would be great.
We (the build2 project) have been working on this problem for the past 8 years and the result is pretty usable, IMO. In particular, we have Boost packaged[1] and the result builds[2] all its dependencies, including OpenSSL and ICU, from source on all the major platforms/compilers using build2. The package manager provides all the necessary mechanisms, such as conditional dependencies, dependency configuration, etc.[3], to solve what is (IMO and as echoed by our users) the biggest barrier to Boost's adoption: it's insane library dependence. And by "insane" here I don't mean just "heavy" (which is definitely the case), but also literally, as in, some of the dependencies just do not make any sense. Like libboost-multi-index depending on libboost-regex and thus ICU. Besides the build system and package manager, the build2 project also provides the CI service that doesn't attempt to cobble together something usable from what's out there and get by with whatever free resources happened to be currently available from GitHub. The result is a reliable and stable service that covers[4] all the major platforms and compilers, including legacy ones. So I believe the technology is there. The question is whether there is an appetite for change. [1] https://cppget.org/?packages=libboost [2] https://cppget.org/?builds=libboost [3] https://build2.org/bpkg/doc/build2-package-manager-manual.xhtml#manifest-pac... [4] https://ci.cppget.org/?build-configs