Re: A proposal for a modern build-system

From: Дмитрий Архипов (grisumbras_at_[hidden])
Date: 2025-05-06 12:25:03

ср, 16 апр. 2025 г. в 15:22, Hassan Sajjad via Boost <boost_at_[hidden]>:
>
> Hi.
>
> I compiled 25 Boost libraries with C++20 header-units, including examples
> and Tests of a few.
> This resulted in a 1.44x speed-up if we exclude the scanning. Scanning was
> as slow as the header-unit build.

If this is a request for endorsement, then the problem is that the
tool/library in question is not really documented. First, compare your
README with CMake's tutorial
https://cmake.org/cmake/help/latest/guide/tutorial/A%20Basic%20Starting%20Point.html
or B2's tutorial
https://www.bfgroup.xyz/b2/manual/main/index.html#b2.tutorial. Both
explain what file to create, what to put in there, what command to
invoke from the shell. Your simple C++ example
(https://github.com/HassanSajjad-302/HMake?tab=readme-ov-file#c-examples)
starts in the middle of the file, and is definitely more hand-wavy.
After reading the paragraphs following the code snippet I am not sure
what commands I need to invoke.

So, a supposed benefit of HMake is that you don't need to learn a new
syntax. But learning a new library's API can be a significant task on
its own.

void updateBTarget(class Builder &builder, unsigned short round) override

What is a "round" here? I am pretty well-versed in build system lingo,
and I have no idea. In the following paragraph you explain that it is
related to how C++ modules are built (in HMake and in CMake). There
are no "rounds" in C++ modules spec or in CMake's document on how to
use it with modules. So, this concept is particular to HMake. This
highlights the fact that you need a thorough documentation of the API.
WIthout it your tool/library is unusable in a serious scenario.

Let's now compare a minimal C++ project in CMake, B2 and HMake.

// HMake
#include "Configure.hpp"
void configurationSpecification(Configuration &config)
{
    config.getCppExeDSC("app").getSourceTarget().sourceFiles("main.cpp");
}
void buildSpecification()
{
    getConfiguration();
    CALL_CONFIGURATION_SPECIFICATION
}
MAIN_FUNCTION

# CMake
cmake_minimum_required(VERSION 3.12)
project(Tutorial)
add_executable(app main.cpp)

#B2
exe app : main.cpp ;

I don't see how HMake is an improvement. It's neither shorter nor more
readable. For example, waht is "DSC"?
This also highlights a common annoyance with using a regular
programming language for build scripts: build scripts connect sources
with targets, their names are strings, so you have to use a lot of
quoting.

Finally, let's consider getConfiguration. From the README I gather
that the build script has to contain a description of every
configuration that the project supports. That is, users can't
experiment with a new configuration without modifying the build
script. This is completely inadequate in my opinion. It is
particularly inadequate for open source software projects. From the
same description I gather that hmake also has to create a dedicated
directory for each configuration. Note that the current main build
system Boost uses (B2) does not work like that. It creates
configurations on the fly from the user's build request and the
targets' requirements. There's also no "active configuration" in B2,
it can build multiple configurations simultaneously.

My main point is still the lack of documentation. Without
documentation there could be no discussion of endorsement, as we
simply cannot evaluate what to endorse.