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.
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 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.
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…