|
Boost : |
From: Hassan Sajjad (hassan.sajjad069_at_[hidden])
Date: 2024-03-22 13:31:32
>
> 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_at_[hidden]> wrote:
> On 21.03.24 18:34, Hassan Sajjad via Boost 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
> 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_at_[hidden])
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk