Re: Fwd: A proposal for a modern build-system

From: Hassan Sajjad (hassan.sajjad069_at_[hidden])
Date: 2024-04-10 00:25:53

>
> Nice, thank you.
>

Welcome.

 so I would like to know if I
> could use a dependency that only has hmake support (and no CMake)
>

This is not on the priority list. But since you mentioned, it will be in my
mind. Currently, I am working on the main selling point "Easy to use
build-system for mega-projects with state-of-the-art C++20 modules
support". This alone will get me a lot of users. CMake support would be
added if it is a positive cost-benefit.

Can you please publish an example to demonstrate how to achieve this
> assuming that CMake support gets removed from Boost and only hmake
> support is left there one day?
>

I am not advocating for CMake support removal. I am just advocating for my
build-system's addition. If the response is positive and the wider
community adopts HMake, only then remove CMake. But let's not think that
far.

For both questions it would probably be a lot more helpful to see them
> addressed in documentation/examples of the repository itself. (If you
> just answer it here, the answers would "get lost", while they would be
> easy to find if you put sample code into the repository.
>

Ok. I will.

do you have any business plan to guarantee development of hmake
> for the foreseeable future
>

Currently, I have a similar plan to CMake. Get funded from "Big Brothers".

so that we can rely on bugs getting fixed
> in a timely manner and missing features being implemented long enough
> that our effort won't have to be repeated again (to rewrite the build
> system back to something else due to lack of support in hmake)
>

For the foreseeable future, I am available for contracting. This might
change if HMake does not get traction.

Assuming Boost would in fact fund you. What would you suggest to
> do with the remaining two build systems? Drop one or both of them?
>

We can drop b2 immediately. CMake will remain for the foreseeable future.

 And since there would definitely
> be more bugs and features popping up in the future: how do you imagine
> maintaining hmake in the long run when that one month of funding is
> over?
>

HMake is a high-quality codebase with extensive testing. It is in C++20 and
follows best-practices. It will be similar or easier for anyone to maintain
my build system than b2.

On Tue, Apr 9, 2024 at 11:02 PM Mojca Miklavec <
mojca.miklavec.lists_at_[hidden]> wrote:

> Hi,
>
> On Tue, 9 Apr 2024 at 11:57, Hassan Sajjad via Boost wrote:
> >
> > I've added a new section to the documentation
> >
> https://github.com/HassanSajjad-302/HMake?tab=readme-ov-file#hmake-architecture
> .
> > Please spend some time exploring this. I believe you will like it.
> >
> > I wrote hmake.cpp for compiling Boost Math with C++20 modules,
> > which you can find at
> > https://github.com/HassanSajjad-302/math/blob/modules/hmake.cpp.
>
> Nice, thank you.
>
>
> Please keep in mind that I'm just a random user (I'm not affiliated
> with Boost development in any way). But I would like to better
> understand a few use cases.
>
> 1.) I have a large C++ project written with the CMake build system
> that uses FetchContent to download and compile Boost sources on the
> fly (so that we don't have to store boost sources inside our own
> codebase). Rewriting the build system of that main project from CMake
> to hmake would be way too expensive, so I would like to know if I
> could use a dependency that only has hmake support (and no CMake).
> That project needs to be cross-compiled to aarch64-linux on a x86_64
> machine.
>
> Can you please publish an example to demonstrate how to achieve this
> assuming that CMake support gets removed from Boost and only hmake
> support is left there one day?
>
>
> 2.) I'm also interested in a different scenario. Let's say that I'm
> willing to invest a lot of time/money into rewriting the build
> configuration for my CUDA project into hmake, but I need to link to
> another library that only has CMake support. Can you please also
> publish an example written in hmake that only compiles the main C++
> project using hmake, but correctly passes the configuration for
> building the dependency (you can use Boost as a sample dependency)? I
> would like to compile the C++/CUDA project for Windows on a Linux box.
>
>
> For both questions it would probably be a lot more helpful to see them
> addressed in documentation/examples of the repository itself. (If you
> just answer it here, the answers would "get lost", while they would be
> easy to find if you put sample code into the repository.)
>
>
> 3a.) And an unrelated question. Assuming that the company where I work
> decides to spend a lot of time and money rewriting our build system to
> hmake: do you have any business plan to guarantee development of hmake
> for the foreseeable future, so that we can rely on bugs getting fixed
> in a timely manner and missing features being implemented long enough
> that our effort won't have to be repeated again (to rewrite the build
> system back to something else due to lack of support in hmake)? I'm
> particularly worried about this aspect of the equation because you
> mentioned that you wouldn't be able to afford to work on hmake in the
> future unless you get some funding right away.
>
> 3b.) Assuming Boost would in fact fund you. What would you suggest to
> do with the remaining two build systems? Drop one or both of them?
> Keep all three build systems around? And since there would definitely
> be more bugs and features popping up in the future: how do you imagine
> maintaining hmake in the long run when that one month of funding is
> over?
>
> Thanks a lot,
>     Mojca
>