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`
In your example C++ is used which means the possible things you can do are literally unlimitted. This makes it much harder to use.
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 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