Please, don't top-post.
Sorry, what do you mean by that? I use Reply All button in Gmail. 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.
No, except the first time, the build-system is very simple to setup and use. You need to run 3 commands to build a project from scratch. It is just one more compared to CMake. Also, build-system is designed such that you need not edit your hmake.cpp again and again. It supports wild cards. 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.
No. Advanced stuff is much easier in hmake. I can see
you're explicitly using std::filesystem in some examples, and that reinforces my suspicion.
std::filesystem is much better than CMake filesystem API or any other build-system's filesystem API. And for anything advanced, much less verbose as-well. 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 did not submit it for production use. I compiled just one configuration. I think it was successful. You can run the Example.exe which depends on 3 DLLs. Anyway, it was just for demonstration and not for production use. 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.
I would love to address if you have any specific complaints regarding documentation. Also, SFML looks like a much smaller library than Boost. But it could be considered a middle-sized project. And I don't see a reason for my build-system to not scale. 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.
I feel that you are in the minority group. Most devs see modules as the future. And with this paper https://lists.isocpp.org/sg15/2023/11/2106.php, their adoption will be much quicker. Modules are not the only benefit of HMake. By the way, what features you will like in a futuristic build-system? HMake might support them. 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.
If successful, then we might deprecate at least one of them. On Fri, Mar 22, 2024 at 5:20 PM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
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.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost