Re: A proposal for a modern build-system

From: Hassan Sajjad (hassan.sajjad069_at_[hidden])
Date: 2024-03-25 14:49:14

>
> 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/Features.hpp

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_at_[hidden]> 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
>