Re: A proposal for a modern build-system

From: Hassan Sajjad (hassan.sajjad069_at_[hidden])
Date: 2025-05-06 19:39:04

>
> It seems like a feature gap that can be fixed at CMake level - either by
> cmake developers or by external patch.
>
> Have you considered talking with CMake developers about it and/or
> submitting
> a patch? What do they think about this?

This is a little funny. If CMake developers can not, how can I? I can only
talk about how my build-system supports header-units. Also, I should not
have said, "CMake can not support C++20 header-units". Anything is possible.

Header-Units support is built on the following four features in HMake.

1) Next-Gen build-algorithm

 HMake build-algorithm support both dynamic nodes and dynamic edges. CMake
supports modules through Ninja, which only supports dynamic edges. Example6
and Example7 in HMake Architecture section demonstrate this capability.

2) Vertical Integration

HMake is both a build-system generator and a build-system itself. Ninja
supports dynamic edges through a separate process. While building modules,
it launches a new process that consumes all of the scanning output and
outputs a file in Ninja consumable format. Ninja then consumes this file to
learn about the dynamic edges. While HMake does all of this itself. Suppose
Ninja supports dynamic nodes, and even then, to ensure a header unit is
built before the consumer, it will need to launch a new process to
establish the dependency. It will have to do this every time it discovers a
new header-unit.

And even then, it will have to determine what compile-command to use with
that header-unit. Suppose the user wants to build ASIO with
ASIO_STANDALONE. Only the ASIO header-units should be built with this
macro. ASIO header-units can potentially be discovered in any of its
dependent targets. HMake goes over the list of header-unit-includes to
determine the directory from which this header-unit is coming. And then the
mapping of the directory to target to determine the cpptarget to attach
this header-unit to. i.e the target whose compile-command will be used to
compile this header-unit.

Ninja lacks the context to do all this. CMake will have to turn to a
build-system itself to support header-units.

3) Game-Changing Feature, Node

HMake has another feature called Node (explained in documentation). For a
module file, to support incremental build, HMake caches its
header-includes, module-deps, header-unit-deps, compile-command,
scanning-command. Without the Node feature, this cache will explode. Node
feature results in little build residue. I estimate that for full Boost,
for full Configuration, it will be 1MB. This ensures ultra-fast loading,
ultra-fast performance.

4) C++

While this is often contended, I think this is extremely important.
E.g., now I plan to remove the scanning support and add scanning-less
support. C++ allows for quick iteration. It allows one to focus on the
problem instead of the DSL.

All in all, as it stands, this is a fundamental change.

Best,
Hassan Sajjad

On Tue, May 6, 2025 at 12:52 PM Artyom Beilis via Boost <
boost_at_[hidden]> wrote:

> > . I am proposing to replace b2.
>
> While I can agree that b2 isn't particularly good build system by any
> stretch of imagination
>
> There was a long and yet incomplete effort of moving to CMake that most
> around
> there are familiar with. CMake works very well and is very well
> supported all around.
>
> Replacing one not-so-good homebrew system that was at least polished
> with yet another homebrew system is a horrible idea.
>
> Boost needs _less_ of "non-invented-here-syndrome": not _more_ of it
>
> Refrasing Stroustrup there are two types of build systems - everybody
> complains about and nobody uses,
> and cmake is one everybody is complaining about ;-)
>
> > I mean today CMake is the most common industry standard build system
> > > that works really well.
> > > Why would you want to use it over something like this?
> >
> >
> > CMake can not support C++20 header-units. One benefit that I forgot is
> that
> > once you have compiled your project with header-units in HMake and you
> want
> > to move to C++20 modules,
>
> It seems like a feature gap that can be fixed at CMake level - either by
> cmake developers or by external patch.
>
> Have you considered talking with CMake developers about it and/or
> submitting
> a patch? What do they think about this?
>
> I'm sure they are aware of the problem :-)
>
> >
> > By caching the results and not running tests every time. Also,
> > configure.exe uses the same code that is used by build.exe. It is fully
> > parallel as well.
>
> You don't reconfigure each and every build... cmake caches _a lot_
> sorry but it seems to be a false statement.
>
> Best
> Artyom
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>