Re: A proposal for a modern build-system

From: Hassan Sajjad (hassan.sajjad069_at_[hidden])
Date: 2025-05-06 23:13:36

>
> 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.
>

I stay motivated because HMake has a lot of benefits compared to the
competitors.  Commercial backing will indeed be seriously helpful.

On Tue, May 6, 2025 at 6:43 PM Jonathan Coe via Boost <boost_at_[hidden]>
wrote:

> 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
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>