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

From: Hassan Sajjad (hassan.sajjad069_at_[hidden])
Date: 2024-04-11 02:02:18

I had not committed the latest hmake.cpp in repo
https://github.com/HassanSajjad-302/SFML. The older one would not have
worked with the latest changes in the HMake API. It works perfectly now.
Sorry for the trouble.

On Wed, Apr 10, 2024 at 5:25 AM Hassan Sajjad <hassan.sajjad069_at_[hidden]>
wrote:

> 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
>>
>