Source code exchange between compilers simplification

[dhombios]

Ada reference manual doesn't specify standard file extensions for the source code of programs and, therefore, each compiler has adopted its own conventions. As a consequence, exchanging code between compilers requires some tuning to allow it recognizing the source files. For internal programs or software distributed as compiled binaries this might not be a problem, but it can be a limitation for package managers. As an example, alire is currently just compatible with gnat, which limits code reusability.

Taking into account that there seems to be a community interested in sharing resources for the Ada language, having a standard self-contained format for exchanging packages could improve code reusability between projects. Ideally, those files would also contain the required resources and some kind of documentation. In addition to that, ensuring that those packages are compatible with any Ada compiler could be useful, despite not being strictly necessary

[sttaft]

Do you have some specific exchange format in mind?

[dhombios]

I can think of two possibilities taking into account approaches used by other languages. The first one could be using a zip file (or any other archive format as ISO) that contains the source code and required resources (files that need to be copied to the folder that contains the executable as images, configuration files or database files). This is the approach used by Java (jar files) and python (wheels), although in those cases they contain a version of the program converted to bytecode to reduce it as those languages are based on a virtual machine.

A second option could consist in mixing all sources into a single text file (similar to the single header C libraries that are becoming quite common). As far as I know Ada specification doesn't forbid doing this, so it might be easier. However, in this case embedding binary resources might be trickier.

In both cases it would be important to ensure that all compilers use the same extension for package exchange files (or crates in alire terminology), as they need to be read by any Ada compiler without having to modify them or edit the IDE configuration. The main advantage of using a self contained file is to avoid collisions between the source code files of different packages downloaded by the package manager.

Regarding documentation, easy approaches if a zip file is used could consist in assuming that it is included in the specification of the package as comments, so it would be possible to ask the compiler to show it without unpacking the archive. Another possibility could consist in assuming that comments above the first line of code of the specification contains the description of the package (which is the one used by matlab). In both cases defining a simple markup language for comments could help formatting documentation, but it would add complexity to this proposal. In case a text file is used this wouldn't be necessary, as it could be read with any text editor

Finally, adding a way to indicate the version of the package might be important to simplify managing those files with a package manager

[dhombios]

With respect to documentation, there's a proposal in adacore repository that could solve that problem in case of using zip files: AdaCore/ada-spark-rfcs#44

[Fabien-Chouteau]

As an example, alire is currently just compatible with gnat, which limits code reusability.

Just to clarify things a little bit, Alire is not just compatible with GNAT. Alire uses gprbuild which will default to parent-child.ads/parent-child.adb filenames, but you can configure this for each project. See Naming Schemes. GPRbuild is actually designed to be compatible with different formats and toolchains.

[dhombios]

As an example, alire is currently just compatible with gnat, which limits code reusability.

Just to clarify things a little bit, Alire is not just compatible with GNAT. Alire uses gprbuild which will default to parent-child.ads/parent-child.adb filenames, but you can configure this for each project. See Naming Schemes. GPRbuild is actually designed to be compatible with different formats and toolchains.

Thanks for clarifying this, I thought it wasn't compatible. This makes alire even more interesting