Fwd: A proposal for a modern build-system
On 23/03/2024 13:16, Hassan Sajjad wrote:
Hi.
Could you please confirm if my proposal is under consideration? If so, when can I expect an update regarding its status?
Sorry for the delay, I had personal issues during those days. I've read the thread, and since now I can't see any serious issue or problem that make me think that the actual build system must be replaced. Maybe updated, but not replaced. For explaining more in detail my point of view (that, I will not ever repeat too many times, it's my personal one, so other people can have other ideas about it): - Boost does not pay people (as far as I know). You're asking for compensation in the first message, but nodoby will pay it, and nodoby asked for it. - I agree with others that three month of development are a bit too optimistic, and also in this case we must maintain two different build systems instead that one. - In the thread I've read many messages like "b2 can do this", "well, also hmake", but no messages like "hmake can do it and b2 it's not able to do it" "oh really? I'd love to have it!". I don't see any important use case that's requested by the community and that hmake will provide while b2 not. So the community wil use hmake to do the same things that at the moment it does with b2. - There's already another build system, even if not much official, and that's cmake. It works well and it's widely used, and that's supported by many package managers, like vcpkg. I have to say that hmake will not be used by them, so it will be limited to the scope of build boost like b2 actually does. Even in this case, it does not add anything. Basically, in the entire thread, in my opinion, there's not a single point that le me think that hmake will make the like easier to boost community. At most we'll have another tool that make the same things. And, repeating myself, I can see that new features actually not supported by b2, pratically modules, are easier to be implemented in b2 instead of using another build system and obligate the entire community to learn another tool for a feature that for now only a few of them will use. In addition to this, I strongly think that instead of a new build system I'll spend some effort, if necessary, in improving existing alternatives, like cmake, that are already widely used by the developer community around the world. Regards Daniele Lupo
Boost does not pay people (as far as I know). You're asking for compensation in the first message, but nodoby will pay it, and nodoby asked for it.
I look forward to the official word on my proposal. Without compensation, it will not be possible for me to work on it. I agree with others that three month of development are a bit too
optimistic, and also in this case we must maintain two different build systems instead that one.
I would like to term the timeframe as realistic and not too optimistic at all. - In the thread I've read many messages like "b2 can do this", "well,
also hmake", but no messages like "hmake can do it and b2 it's not able to do it" "oh really? I'd love to have it!". I don't see any important use case that's requested by the community and that hmake will provide while b2 not. So the community wil use hmake to do the same things that at the moment it does with b2.
b2 does not support header-units and modules and I believe the community is interested in these C++20 features. And, repeating myself, I can see that new features actually not
supported by b2, pratically modules, are easier to be implemented in b2 instead of using another build system
I think you are wrong in this evaluation. Boost build maintainer could comment on that. I strongly think that instead of a new build
system I'll spend some effort, if necessary, in improving existing alternatives, like cmake, that are already widely used by the developer community around the world.
You won't be able to compile Boost with modules / header-units in CMake or b2 in the next 3 months. I strongly think that I am offering the best return on investment. On Tue, Mar 26, 2024 at 7:24 AM Daniele Lupo via Boost < boost@lists.boost.org> wrote:
On 23/03/2024 13:16, Hassan Sajjad wrote:
Hi.
Could you please confirm if my proposal is under consideration? If so, when can I expect an update regarding its status?
Sorry for the delay, I had personal issues during those days.
I've read the thread, and since now I can't see any serious issue or problem that make me think that the actual build system must be replaced. Maybe updated, but not replaced.
For explaining more in detail my point of view (that, I will not ever repeat too many times, it's my personal one, so other people can have other ideas about it):
- Boost does not pay people (as far as I know). You're asking for compensation in the first message, but nodoby will pay it, and nodoby asked for it. - I agree with others that three month of development are a bit too optimistic, and also in this case we must maintain two different build systems instead that one. - In the thread I've read many messages like "b2 can do this", "well, also hmake", but no messages like "hmake can do it and b2 it's not able to do it" "oh really? I'd love to have it!". I don't see any important use case that's requested by the community and that hmake will provide while b2 not. So the community wil use hmake to do the same things that at the moment it does with b2. - There's already another build system, even if not much official, and that's cmake. It works well and it's widely used, and that's supported by many package managers, like vcpkg. I have to say that hmake will not be used by them, so it will be limited to the scope of build boost like b2 actually does. Even in this case, it does not add anything.
Basically, in the entire thread, in my opinion, there's not a single point that le me think that hmake will make the like easier to boost community. At most we'll have another tool that make the same things. And, repeating myself, I can see that new features actually not supported by b2, pratically modules, are easier to be implemented in b2 instead of using another build system and obligate the entire community to learn another tool for a feature that for now only a few of them will use. In addition to this, I strongly think that instead of a new build system I'll spend some effort, if necessary, in improving existing alternatives, like cmake, that are already widely used by the developer community around the world.
Regards
Daniele Lupo
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tue, Mar 26, 2024 at 1:25 PM Hassan Sajjad wrote:
I look forward to the official word on my proposal. Without compensation, it will not be possible for me to work on it.
Any entities on this list (organizations or individuals) that might be interested in your proposal are welcome to encourage or offer support for it. If all such entities are silent, that is also an answer. Glen
Hello Everyone, I want to share a few updates to my proposal. I fixed a few bugs in my build-system and improved its architecture. The core algorithm is better, easier, and simpler to use. I am very confident about the full correctness of the build-system and will appreciate it if you find and report a bug. 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. There's been ongoing discussion regarding compiling and utilizing Boost as C++20 modules. My build system is well-suited for this task. Once we've compiled Boost with C++20 header-units, transitioning to a C++20 modules-based configuration will require minimal changes in the configuration file. However, adjustments in the source code will be necessary. If you approve the proposal, we can aim to compile Boost with C++20 header-units within 3 months and with C++20 modules within 6-7 months. 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. I'm willing to work on this proposal for standard C++ developer compensation for 1 month instead of the previously quoted 3. This will likely be my final unsolicited email regarding this matter. Thank you for considering these updates. Best, Hassan Sajjad On Tue, Mar 26, 2024 at 10:44 PM Glen Fernandes <glen.fernandes@gmail.com> wrote:
On Tue, Mar 26, 2024 at 1:25 PM Hassan Sajjad wrote:
I look forward to the official word on my proposal. Without compensation, it will not be possible for me to work on it.
Any entities on this list (organizations or individuals) that might be interested in your proposal are welcome to encourage or offer support for it.
If all such entities are silent, that is also an answer.
Glen
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
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
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
participants (4)
-
Daniele Lupo -
Glen Fernandes -
Hassan Sajjad -
Mojca Miklavec