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@gmail.com> 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@gmail.com> 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-architect... .
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