GPR external variable clashes

[pmderodat]

In project files, all external variables belong to the same namespace. As a result, several project files can declare incompatible requirements. For instance, with GNAT Community 2019, we have in XML/Ada’s shared.gpr:

   type Mode_Type is ("distrib", "Debug", "Production", "profile", "coverage",
                      "nochecks");
   Mode : Mode_Type := external ("BUILD", "Production");

while in GPRbuild’s gpr.gpr, we have:

   type Build_Type is ("debug", "production", "coverage", "profiling");
   Bld : Build_Type := external ("BUILD", "production");

Outside of Alire, this is not a problem since users generally install XML/Ada before they attempt to build GPRbuild/LibGPR. By default, GPRinstall removes external variables, so there is no BUILD external variable in installed project files.

Alire does not use gprinstall to satisfy dependencies, so we have this problem. Of course we can decide that projects handed over to Alire should only use “unique” scenario variables to prevent such clashes to happen in the first place, but this means that a lot of existing released projects won’t be able to build with Alire, so including all releases of GNATcoll[1], and projects using GNATcoll. This is not specific to GNATcoll, as I believe that using common names for external variables is a GPR users long standing practice.

We could also decide to change the way Alire provides dependencies, switching to the use of GPRinstall. Is the alire/cache hierarchy documented and guaranteed to be stable, anyway?

The last option I see would be to allow crates to come with patches to apply to the downloaded sources, so that crate maintainers could rename these variables on the fly to rectify existing releases. This mechanism is common at least in Linux distribution packaging.

Thoughts?

[1] Today’s GNATcoll crate states that it has no dependency whereas it depends on both XML/Ada and LibGPR. It worked so far because all users attempted to use Alire with either GNAT Community (which ships all these libraries) or with a FSF install that already has these installed. I found this issue while trying to fix this crate.

[mosteo]

Would gprinstall solve all of our problems? (Related: #94)

In my mind the alire/cache was not intended to be a stable thing for releases to reference (that gprinstall would be better suited for that, was my impression).

@Fabien-Chouteau expressed some thoughts on gprinstall in gitter. He will have valuable context for this I guess.

I have always found the idea of post-patching totally unappealing, so I'd try to avoid that, if possible.

[pmderodat]

Ah, I see: Fabien noticed that the inconvenient of using gprinstall is that scenario variables are lifted in installed projects. This is indeed inconvenient.

Yet, I find the fact that all current releases of AdaCore’s projects can’t be properly imported in Alire very uncomfortable. @Fabien-Chouteau what do you think about this business?

[mosteo]

To summarize my understanding: we are seeing here two extremes:

1. Compiling everything at once via an [aggregate] project. Obvious problems: configuration clashes, not well-supported aggregate projects, and also that an aggregate project cannot refer to other aggregates that might be used by upstream projects. Main advantage, it's kind of stateless.

2. Every dependency is to be compiled and installed individually, incrementally creating an environment that further dependents use during their compilation. I'm not familiar with the peculiarities of this one, besides that I dislike the statefulness of it, but it seems more general in the current software landscape.

The first one is appealing to me because of simplicity, but I understand it may not be realistically capable enough. I always try to make my projects buildable that way though.

[Fabien-Chouteau]

Yet, I find the fact that all current releases of AdaCore’s projects can’t be properly imported in Alire very uncomfortable. @Fabien-Chouteau what do you think about this business?

Could the install step be optional?

I am not 100% against gprinstall but I have reservations. In particular I don't know of the "abstact" projects that I have (GESTE, lvgl-ada) will work with gprinstall. These projects are "abstract" because they require a configuration source file to be provided each time the lib is used.

This might also get in the way of the symlinks proposal #288.

[Fabien-Chouteau]

To summarize my understanding: we are seeing here two extremes:

1. not well-supported aggregate projects

I was planning to propose a change to remove the alr_build.gpr aggregate project and replace it with setting up the GPR_PROJECT_PATH env variable before calling GPRbuild. I guess that if we do use gprinstall we will have to do the same.

2. Every dependency is to be compiled and installed individually, incrementally creating an environment that further dependents use during their compilation.

This could make sense when depending on bin/apps/programs, for instance for code generation. Because they need to be compiled first and available when build the target crate.

[mosteo]

I was planning to propose a change to remove the alr_build.gpr aggregate project and replace it with setting up the GPR_PROJECT_PATH env variable before calling GPRbuild. I guess that if we do use gprinstall we will have to do the same.

Agreed, this is something we can already do independently of later addressing the gprinstall part.

[Fabien-Chouteau]

An update on this, we have changed the names of externals in AdaCore libs project files to avoid clashes.