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. I believe mine is the easiest-to-use build system out there, especially for C++ development. 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. I feel it has now passed from the training academy. More documentation would be added as more features would be added. 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. And I have experience with Boost build-system b2. 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. Many libraries have first come to boost and then come to C++ standard. You should sponsor me because if this succeeds, others might adopt it as as-well. For even bigger projects like UE5, the advantage of compiling with header-units would be bigger >4x compared to my estimate of >2.5x in clean-build for Boost. On Fri, Mar 22, 2024 at 2:05 AM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
Hi.
Preface:
C++20 modules and header-units are a great addition to C++. There are numerous benefits of these. One of them is a faster compilation. Conventional build-systems however are unable to benefit from C++20 modules or header-units. Boost current build-system b2 does not support C++20 modules or header-units. CMake does not support C++20 header-units https://gitlab.kitware.com/cmake/cmake/-/issues/25293.
I developed the build-system HMake https://github.com/HassanSajjad-302/HMake. It is in C++ and MIT Licenced. It supports drop-in header-files to header-units replacement. While compilers support processing a
On 3/21/24 20:34, Hassan Sajjad via Boost wrote: header-file
as header-unit, no other build-system supports this feature.
With this I compiled SFML with C++20 header-units
https://www.reddit.com/r/cpp/comments/1555g6b/hmake_build_system_02_compilin... .
In the post, I mentioned that 2-3.5x speed-up was achieved but I did some more testing recently and an even better speed-up of 2.7-4.7x was achieved i.e., the speed of header-units is further improving with recent iterations.
Proposal:
I want to propose my build-system HMake for boost.
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.
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.
Besides its already state-of-the-art C++20 modules and header-units support, it will be the first to support https://lists.isocpp.org/sg15/2023/11/2106.php or https://lists.isocpp.org/sg15/2023/11/2146.php if any of this gets implemented. These papers present ideas for faster module adoption and avoiding redundant module compilations. These need support from build-system. This way boost could be a breeding ground for C++20 modules adoption. Also, I have good experience with boost's current build-system b2 as a good portion of HMake's current API is inspired by it.
Timeframe:
I will complete this proposal in 3 months.
This is a very ambitious time frame, IMO.
Deliverables:
1) 2-months: Boost basic configuration compiled with C++20 header-units. This is more of a lone sprint. 2) 3-months: All boost current configurations + new with header-units and modules + tests and examples. This will require more active involvement by the current maintainers. I will give weekly updates here and will make a video after 2 months presenting the progress made. This will be to help other contributors so they can ensure that their library is fully supported.
Cost:
Standard C++ Developer Compensation for 3 months (Negotiable). Payments are to be issued monthly. But you can back out at any point in case you are unsatisfied with development speed or direction.
I'm not the one to make funding decisions, but I don't see why Boost would pay for this work. It's not like Boost is in dire need of a new build system.
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.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost