# Improved Ada language support, gauging interest in a GPRbuild generator
**URL:** https://discourse.cmake.org/t/improved-ada-language-support-gauging-interest-in-a-gprbuild-generator/15485
**Category:** Development
**Created:** [January 30, 2026, 12:46am UTC](https://discourse.cmake.org/t/improved-ada-language-support-gauging-interest-in-a-gprbuild-generator/15485 "2026-01-30T00:46:41Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@nsmith](https://discourse.cmake.org/u/nsmith)
#### Post date: [January 30, 2026, 12:46am UTC](https://discourse.cmake.org/t/improved-ada-language-support-gauging-interest-in-a-gprbuild-generator/15485/1 "2026-01-30T00:46:41Z")
First time posting here, I wanted to throw out the idea of developing a new native generator for GPRbuild. It seems like it would be a great way to add support for the Ada language ecosystem, and seems (famous last words) like it would be relatively straightforward to develop.
Background on GPRBuild:
- [GPRbuild - learn.adacore.com](https://learn.adacore.com/courses/GNAT_Toolchain_Intro/chapters/gprbuild.html)
- [GPRbuild and GPR Companion Tools User’s Guide — GPR Tools User's Guide 27.0w documentation](https://docs.adacore.com/gprbuild-docs/html/gprbuild_ug.html)
I’m interested in taking it on as a project, but wanted to first gauge if this is something there would be any openness towards.
---
### Author:  [@marc.chevrier](https://discourse.cmake.org/u/marc.chevrier)
#### Post date: [January 30, 2026, 9:40am UTC](https://discourse.cmake.org/t/improved-ada-language-support-gauging-interest-in-a-gprbuild-generator/15485/2 "2026-01-30T09:40:34Z")
In fact, supporting a new language (`Ada` for instance) and integrating a new build generator are orthogonal.
Supporting the `Ada` language in CMake does not require supporting `GPRBuild` tool. I already did, some time ago, some proof of concept of supporting the GNAT `Ada` (see [CMake Ada support](https://gitlab.kitware.com/marc.chevrier/cmake/-/tree/ada-language?ref_type=heads) with `Makefile` and `Ninja` generators. This support raise some challenges:
- Ada has a `bind` phase before the `link` (concept not currently supported by `CMake`)
- Compiling an `Ada` file generate two different files (object file and `ALI` file)
- Mixing `Ada` and other languages as part of one artifact (library or executable) can be not so straitforward.
Now, regarding `GPRBuild` support, it is always a good idea to have a new build tool supported by `CMake`, especially because `GPRBuild` supports multiple languages. But I don’t know how easy is a such integration.
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [January 30, 2026, 2:59pm UTC](https://discourse.cmake.org/t/improved-ada-language-support-gauging-interest-in-a-gprbuild-generator/15485/3 "2026-01-30T14:59:40Z")
> [@marc.chevrier](#):
>
> Compiling an `Ada` file generate two different files (object file and `ALI` file)
I believe the `ALI` files are anaogous to C++ and Fortran modules (in that they end up requiring ordered compilations).
---
### Author:  [@marc.chevrier](https://discourse.cmake.org/u/marc.chevrier)
#### Post date: [January 30, 2026, 3:28pm UTC](https://discourse.cmake.org/t/improved-ada-language-support-gauging-interest-in-a-gprbuild-generator/15485/4 "2026-01-30T15:28:26Z")
Not exactly. `ALI` files are specific to the GNAT implementation and are used for the compilation **and** the bind step (step which define the order of elaboration/initialization of the packages).
By design, `Ada` sources are not related to files but only packages. The GNAT implementation has a specific approach regarding this design: only one package per file. When a file is compiled, it generates an `ALI` file which will be used by other package compilations if they depend on it. And the GNAT compiler is smart enough to detect the dependencies of a package and compiling all of them if needed.
So, in conclusion, the user does not have to handle the `ALI` files, this is only an implementation detail…