Am 23.03.24 um 19:49 schrieb Hassan Sajjad via Boost:
3) And will also require them to know hmake. The alternative is to learn the command-line. The commandline is a closed set. I.e. there are a few allowed switches with a few allowed values. E.g. for b2 it is `b2 variant=release`, `b2 variant=debug` or even `b2 variant=release,debug`
hbuild could be configured to pass command-line options to our hmake.cpp where we can parse them and define configurations based on those variables. Now library authors need to add and maintain code for command-line
In your example C++ is used which means the possible things you can do are literally unlimitted. This makes it much harder to use. parsing just to build. Not an improvement IMO. Especially as it means that different libraries might parse the commandline differently. Especially for Boost which is a collection of libraries, not a single one., although they get built together. Another downside of your example: To build only a release build, which is likely the only thing users care about, you need to set 2 cache variables. This is one reason an established build system is better: People know things like this or they have been solved/improved over the time the build system already exists. Also the supposed benefit of faster compile times isn't convincing for me: In your example you saved 5 seconds. I don't really build often and especially I don't build from scratch often but rather do incremental builds. So the saved time compiling doesn't make up the time writing stuff for a new build system. So my vote would be NO on this proposal. PS: Please also read the mailing list rules as already indicated by others, especially https://www.boost.org/community/policy.html#quoting