As somebody who just studies a whole Ada ecosystem I am learning a lot about GPRbuild and its language. I find this is a pretty interesting build system with features many other build systems do not have.
Looking at alire repository, however, I find that many projects also use GNU make as a kind of frontend to build and install things, sometimes even as a simple wrapper to GPRbuild. I’ve run into problems trying to make alire index more portable and those problems have been easily solved somewhere else.
I consider make ugly and GPRbuild nice and I was wondering why some projects still prefer make.
So the project idea is this:
- Identify most common reasons to use make instead of GPRbuild
- Consider additional features that should be added to the GPR language
- Implement them (preferably also in the older GPRbuild 1)
- Stop using make as a frontend
So far I have identified the following reasons:
- Convenience loops - it is easy for example to build 3 versions of a library looping around multiple
gprbuildinvocations with different-Pparameters. Gem #158: GPRinstall - Part 1 | AdaCore gem suggests to simply run gprbuild/gprinstall in sequence to have a library built for three object format variants. I believe we could support something like this in GPR without introducing general purpose loops (which I think has been avoided on purpose) - Building multiple projects - a variant of above if make is used to invoke multiple GPR projects within the same repository. If aggregate projects are too limited to achieve this, we should figure out what are the obstacles here.
- C language libraries - additional code like GNU autoconf and similar can be used to detect additional external libraries and feed them to the GPR processing. My proposal to solve the most typical use case is to integrate GPR tigher with pkgconf - to allow for example setting linker flags from within the GPR without resorting to the need to provide them externally.
- Code generation - there could be an additional phase before the compilation phase to invoke some additional code generators. I think LangKit based projects and maybe asn1scc should be used to make sure the feature is generic enough to support various code generators. I read somewhere (in the Lisp community) that if code generation is needed, this means that the abstractions that the programming language provides are not rich enough [citation needed], but solving this is definitely out of scope here.
- ….
A special mention goes to LangKit’s manage.py which is used for various aspects of building/confguration. I understand that this might be because some other non-Ada projects might want to use the library.
A major benefit of this is simplification of a whole ecosystem and lowering barriers of entry. Cargo users need only to use cargo. I believe alire is a wrong place to solve this problem. I’d rather be programming GPR than TOML if you ask me.We also do not want to convert the alire index to a full feature ports tree such as ravenports.
Solving all this requires some architectural discussion about where the GPR language should evolve. I am not sure where to start such a discussion, so I am trying here.
Difficulty to solve all of this is hard, but once the design directions are clear this might actually proceed. Good thing here is that we can devise smaller sub-projects to deal with various aspects of this issue.
For myself, I think that adding some kind of pkgconf integration should be easy enough for a newcomer like me to get started.
My apologies if this has been discussed extensively already, but I could not find much references to this, even with some LLM-based tools to search the Internet.
