Re: A proposal for a modern build-system

From: Jonathan Coe (jbcoe_at_[hidden])
Date: 2025-05-06 13:25:53

Hi,

Sharing my thoughts so that the HMake author does not invest time unduly.

Even with exceptional and detailed documentation, this feels like a high-risk change that’s very unlikely to take place without evidence of significant adoption elsewhere. Build systems are hard and most folk seem to prefer familiar foibles over innovation.

If the build system space is interesting, it might be worth spending time improving existing tools (tooling around CMake is challenging) rather than starting from scratch. 

I’m happy to be wrong but don’t suspect that creating a new build system from scratch (without massive commercial backing) is likely to be a path of minimal resistance.

J

> On 6 May 2025, at 13:26, Дмитрий Архипов via Boost <boost_at_[hidden]> wrote:
> 
> ср, 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.
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost