In terms of what my build system does, actually compiling the C++ source files is the easiest 1%. The hard parts are building libraries, processing data files, and packaging the complete project for distribution. Some more specific requirements:
HMake has APIs for some of these and is in the pipeline for some others. HMake is at its core a dependency resolver. So, anything you can do in make, you can do in HMake. In the future, high-end APIs will be available for most languages and common tasks. A common task during package development is compression and build-system generally first checks whether such commands as gzip or bz2 are available. With HMake, a compression API will be in-built that works on all operating systems. I want to build for multiple target operating systems on one
computer, from one source directory, with one invocation of the build system.
Check. Build-system has very good support for this. - I don't like to edit my build specification files every time I add
or remove a file, so I use wildcards extensively in specifying which source files to build.
Check. Build-system has very good support for this. I don't understand other requirements. I can comment if you could give some examples. C++20 modules and header-units is a complex maneuver and build-system is extendable so most likely build-system supports / can support other features as well. On Fri, Mar 22, 2024 at 5:34 PM Rainer Deyke via Boost < boost@lists.boost.org> wrote:
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 21.03.24 18:34, Hassan Sajjad via Boost wrote: header-file
as header-unit, no other build-system supports this feature.
My experience with existing build systems is that they all suck. I currently have my own ad-hoc build system written in Python, and I'd love to be able to drop it, especially since my own system is currently also unable to build C++ modules, but none of the existing build systems I tried were able to meet my needs. I am therefore interested in a new build system in principle, but also extremely picky about which build systems I am interesting in.
In terms of what my build system does, actually compiling the C++ source files is the easiest 1%. The hard parts are building libraries, processing data files, and packaging the complete project for distribution. Some more specific requirements:
- Builds should be hermetic. Compiling the same project with the same command-line arguments on different computers should result in bit-for-bit identical results. (I currently handle this by compiling in a Docker container.) - I want to build for multiple target operating systems on one computer, from one source directory, with one invocation of the build system. - I don't like to edit my build specification files every time I add or remove a file, so I use wildcards extensively in specifying which source files to build. - Some executables need to be built for the target platforms. Some only need to be built for the build platform, so that I can run them as part of the build process. - The set of artifacts produced from one (data) source file is not known until the source file is processed. (Example: unzipping a zip file as part of the process of building the library contained in the zip file.)
-- Rainer Deyke (rainerd@eldwood.com)
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost