Please, don't top-post. https://www.boost.org/community/policy.html#quoting On 3/22/24 12:59, Hassan Sajjad wrote:
Also, personally, I don't think C++ is a good choice for a build system language. The build system files are unnecessarily verbose, and the build process seems too complex.
This is a subjective opinion. I appreciate it but would appreciate it more if you could provide actionable feedback.
This is the opinion I got from reading through the readme. For example: <quote> Now, to build the Example you need to run hhelper once and hbuild twice. hhelper will create the cache.json file. cache.json file provides an opportunity to select a different toolset. It has array indices to the arrays of different tools in toolsCache.json. These tools must exist in toolsCache.json for HMake to work. cache.json file also has the commands that hbuild will use to build the configure dll. Running hbuild first time will create the configure dll, linking hconfigure static-lib using whole-archive linker feature. Running hbuild again will load the configure dll and call the func2 with BSMode::BUILD. This will create the app executable in {buildDir}/app. </quote> So one needs to run the build system three times, and possibly edit a json in between to build his project. This is compared to running b2 once, or cmake twice (first to configure, second to build the project), and no editing in between. The editing part is actually a big problem if the building process is to be wrapped in any external tooling, such as package building tools or CI. Then the build system language. Here's an example from the docs, which presumably is the simplest way to build an application: <quote> #include "Configure.hpp" void buildSpecification() { GetCppExeDSC("app").getSourceTarget().SOURCE_FILES("main.cpp"); } MAIN_FUNCTION </quote> Compare this to b2: <quote> exe app : main.cpp ; </quote> or CMake: <quote> add_executable(app main.cpp) </quote> or Meson: <quote> project('simple', 'cpp') executable('app', 'main.cpp') </quote> I don't know how the more advanced stuff like iterating the filesystem or compiling configure-time checks would look like in HMake, but I suspect those will be more verbose and complicated as well. I can see you're explicitly using std::filesystem in some examples, and that reinforces my suspicion.
I'm strongly opposed to supporting a third build system. Especially given that the proposed build system is not mature and hasn't gained wide adoption. In fact, from the GitHub page it looks like a prototype rather than something that was battle tested. I see no documentation besides the readme with a few examples.
It is not battle-tested but ready for one.
It is not, without proper documentation. Another potential issue that comes to mind is, what is the minimum C++ version HMake requires for itself, and what is the minimum C++ version it supports to compile the project? E.g. is it possible to build HMake and the user's project on a system that only supports C++11? Does it support languages other than C++? C and assembler, in particular? I'm asking because Boost is not limited to just C++.
This is a very ambitious time frame, IMO.
While converting SFML, more time was spent on understanding the current build-description compared to expressing it in C++/HMake. SFML basic configuration was achieved in 200 lines. It does not take much time to write 200 lines.
I don't see HMake files in SFML (https://github.com/SFML/SFML), so I presume this was your internal benchmark, and I can't judge how close to the original the translation was. I can believe it was easier *for you* to implement the build scenario in HMake - because you know HMake. It won't be necessarily the case for someone new to HMake, especially without documentation. Also, SFML looks like a much smaller library than Boost.
If we do want to sponsor our build system advance, I think the money would be better spent on improving CMake support in Boost and in implementing features we need in CMake.
I feel that the return on investment that I offer is unmatched. That's due to a fundamentally better approach to my software.
Sorry, I don't see the benefit. I'm not very familiar with modules, but it looks to me that this technology is very far from wide adoption. More than that, it looks like it is very demanding on the developers and, apparently, the ecosystem (case in point - do we now need a whole new build system to leverage modules??) while providing benefits that can be achieved through different means (precompiled headers, ccache, more fine-grained headers, more compiled libraries). More than that, AFAIK, it has fundamental issues with macros. So yeah, modules are a mixed bag, and I don't see support for modules as a worthy goal in the immediate future. If modules are the only benefit HMake promises to provide, that's a weak selling point, IMO. And to reiterate, I'm just not going to support a third build system, whether it is HMake or something else. We're spending enough time on the existing two.