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@lists.boost.org> wrote:
ср, 16 апр. 2025 г. в 15:22, Hassan Sajjad via Boost < boost@lists.boost.org>:
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%20Po... 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