Re: A proposal for a modern build-system

From: Hassan Sajjad (hassan.sajjad069_at_[hidden])
Date: 2024-03-22 13:03:01

>
> 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_at_[hidden]> 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
>