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.
This is not a bad thing. By using C++, users have full power available to them in case they need it. The pattern demonstrated in Example 2 is modeled on Boost build-system b2. So there is a limited set of enmu values that can be assigned to the Configuration. These enums are declared here. https://github.com/HassanSajjad-302/HMake/blob/main/hconfigure/header/Featur... 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.
Firstly, I argued against command-line parsing in favor of editing cache.json file. But, if the user wants command-line parsing, there needs to be just one function used in hmake.cpp that parses arguments and declares configurations based on that. Library authors don't need to edit it. But again, it is not needed in the first place. 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.
I don't see how it is worse than the alternatives. You need to edit one variable in cache.json. That's it. 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.
I compiled the SFML conventional build in the 20s while drop-in build was compiled in the 16s. So, it saved 4s which is 20% in clean-build. The benefit of header-units becomes bigger in bigger projects because it prevents the same file from being compiled repeatedly. It will be very noticeable in Boost compilation which would be, I estimate, 2.5x faster. I compiled Boost in 5mis (300s), so I expect drop-in configuration to build in 2min (120s). Header-units will save me 180s. Also, the incremental build is 2.5x faster. You can test it by editing a file and then measuring 'hbuild' time in conventional and drop-in directories in SFML build-dir. Again, if you are working on a project with numerous dependencies the impact of header-units for the incremental build is bigger because the compiler benefits from using the precompiled code instead of compiling it. This means that >4x improvement could be expected for some libraries. So, the compile-edit-run cycle will become instantaneous. On Mon, Mar 25, 2024 at 4:34 PM Alexander Grund via Boost < boost@lists.boost.org> wrote:
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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost