Re: A proposal for a modern build-system

From: Hassan Sajjad (hassan.sajjad069_at_[hidden])
Date: 2025-05-06 22:25:08

Hi.

Thank you for a detailed comment.

After reading the paragraphs following the code snippet I am not sure
> what commands I need to invoke.

Yes. Now, I see it. I will add the following, and then the explanation.

1) htools with administrative permissions.
2) mkdir Examples/Example1/Build
3) cd Examples/Example1/Build
4) hhelper
5) hhelper
6) build

........

If you did not, do run this
https://github.com/HassanSajjad-302/HMake/blob/main/Projects/Boost/hmake.cpp

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

At scale, hmake.cpp will be much shorter. To be concise, expressive, and
user-friendly is first priority.

I don't see how HMake is an improvement. It's neither shorter nor more
> readable. For example, waht is "DSC"?

Uhh. I will mention this in the documentation. This is short for
"Dependency Specification Controller". This includes pointers to
"CppSourceTarget" and "LinkOrArchiveTarget".
If you set this line
<https://github.com/HassanSajjad-302/HMake/blob/6f0ba0e3850f7008067af5ac3cd6bdf1de688735/CMakeLists.txt#L67>
in
CMakeLists.txt to "Examples/Example1/hmake.cpp", you get full intellisense
for hmake.cpp file through ConfigureHelper and BuildHelper CMake targets.
You can run/debug the configure and build steps by running these targets in
build-dir. I am saying this because I had a comment before DSC template
class declaration.

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.

Specifying new Configurations is very easy. Like boost/hmake.cpp had the
following two configurations defined to benchmark the debug build with
header-units.

    getConfiguration("conventional").assign(TreatModuleAsSource::YES,
ConfigType::DEBUG);
    getConfiguration("hu").assign(TreatModuleAsSource::NO,
TranslateInclude::YES, ConfigType::DEBUG);

Creating build-dirs at build-time will be very slow. HMake creates these in
parallel at configure-time.

Also, this is a top-level API and can be modified per requirements.

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.

This is a recurrent complaint, so I concede. But I don't know where to
start. I will be happy if you provide more ideas.

Best,
Hassan Sajjad

On Tue, May 6, 2025 at 5:25 PM Дмитрий Архипов 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
>