Re: A proposal for a modern build-system

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2024-03-22 12:19:55

Please, don't top-post.

https://www.boost.org/community/policy.html#quoting

On 3/22/24 12:59, Hassan Sajjad wrote:
>     Also, personally, I don't think C++ is a good choice for a build system
>     language. The build system files are unnecessarily verbose, and the
>     build process seems too complex.
> 
> This is a subjective opinion. I appreciate it but would appreciate it
> more if you could provide actionable feedback.

This is the opinion I got from reading through the readme. For example:

<quote>
Now, to build the Example you need to run hhelper once and hbuild twice.
hhelper will create the cache.json file. cache.json file provides an
opportunity to select a different toolset. It has array indices to the
arrays of different tools in toolsCache.json. These tools must exist in
toolsCache.json for HMake to work. cache.json file also has the commands
that hbuild will use to build the configure dll. Running hbuild first
time will create the configure dll, linking hconfigure static-lib using
whole-archive linker feature. Running hbuild again will load the
configure dll and call the func2 with BSMode::BUILD. This will create
the app executable in {buildDir}/app.
</quote>

So one needs to run the build system three times, and possibly edit a
json in between to build his project. This is compared to running b2
once, or cmake twice (first to configure, second to build the project),
and no editing in between.

The editing part is actually a big problem if the building process is to
be wrapped in any external tooling, such as package building tools or CI.

Then the build system language. Here's an example from the docs, which
presumably is the simplest way to build an application:

<quote>
#include "Configure.hpp"

void buildSpecification()
{
    GetCppExeDSC("app").getSourceTarget().SOURCE_FILES("main.cpp");
}

MAIN_FUNCTION
</quote>

Compare this to b2:

<quote>
exe app : main.cpp ;
</quote>

or CMake:

<quote>
add_executable(app main.cpp)
</quote>

or Meson:

<quote>
project('simple', 'cpp')
executable('app', 'main.cpp')
</quote>

I don't know how the more advanced stuff like iterating the filesystem
or compiling configure-time checks would look like in HMake, but I
suspect those will be more verbose and complicated as well. I can see
you're explicitly using std::filesystem in some examples, and that
reinforces my suspicion.

>     I'm strongly opposed to supporting a third build system. Especially
>     given that the proposed build system is not mature and hasn't gained
>     wide adoption. In fact, from the GitHub page it looks like a prototype
>     rather than something that was battle tested. I see no documentation
>     besides the readme with a few examples.
> 
> It is not battle-tested but ready for one.

It is not, without proper documentation.

Another potential issue that comes to mind is, what is the minimum C++
version HMake requires for itself, and what is the minimum C++ version
it supports to compile the project? E.g. is it possible to build HMake
and the user's project on a system that only supports C++11?

Does it support languages other than C++? C and assembler, in
particular? I'm asking because Boost is not limited to just C++.

>     This is a very ambitious time frame, IMO.
> 
> While converting SFML, more time was spent on understanding the current
> build-description compared to expressing it in C++/HMake. SFML basic
> configuration was achieved in 200 lines. It does not take much time to
> write 200 lines.

I don't see HMake files in SFML (https://github.com/SFML/SFML), so I
presume this was your internal benchmark, and I can't judge how close to
the original the translation was.

I can believe it was easier *for you* to implement the build scenario in
HMake - because you know HMake. It won't be necessarily the case for
someone new to HMake, especially without documentation.

Also, SFML looks like a much smaller library than Boost.

>     If we do want to sponsor our build system advance, I think the money
>     would be better spent on improving CMake support in Boost and in
>     implementing features we need in CMake.
> 
> I feel that the return on investment that I offer is unmatched.  That's
> due to a fundamentally better approach to my software.

Sorry, I don't see the benefit.

I'm not very familiar with modules, but it looks to me that this
technology is very far from wide adoption. More than that, it looks like
it is very demanding on the developers and, apparently, the ecosystem
(case in point - do we now need a whole new build system to leverage
modules??) while providing benefits that can be achieved through
different means (precompiled headers, ccache, more fine-grained headers,
more compiled libraries). More than that, AFAIK, it has fundamental
issues with macros.

So yeah, modules are a mixed bag, and I don't see support for modules as
a worthy goal in the immediate future. If modules are the only benefit
HMake promises to provide, that's a weak selling point, IMO.

And to reiterate, I'm just not going to support a third build system,
whether it is HMake or something else. We're spending enough time on the
existing two.