How to handle dependencies already installed?

[pjljvandelaar]

Dear Alire developers,

Many of the users of my alire crate have GNAT Pro and LibAdaLang already installed on their PC.
Building my crate takes quite some time, since the installed version of GNATColl and LibAdaLang are not reused.
In fact, we have regularly problems due to the usage of different versions of libraries in different steps of the build, compile, and release sequence. See e.g. #982 and executions that state the process exited with status -1073741819.

Users of alire can choose that the gnat version and/or the gprbuild version installed in the environment are used.
Should we also allow users to choose that the GNATColl version and LibAdaLang version installed in the environment are used?
Or could alire detect the dependencies are available in the environement and then use them?

I am curious to your answers!

Greetings,

Pierre

[Fabien-Chouteau]

Hi @pjljvandelaar,

GNAT pro and Alire workflows are not always compatible.

One option here would be to remove libadalang from the list of dependencies in you crate, this way gprbuild will use the one from GNAT Pro.

Users of alire can choose that the gnat version and/or the gprbuild version installed in the environment are used.
Should we also allow users to choose that the GNATColl version and LibAdaLang version installed in the environment are used?
Or could alire detect the dependencies are available in the environement and then use them?

This is not planed at the moment and I am not even sure if it is doable. I don't think there is a reliable way to get the version of a library in the system or in GNAT Pro install.

Alire is a source package manager so it is part of the workflow to build from sources. It has drawbacks and advantages.

[pjljvandelaar]

Your suggestion
One option here would be to remove libadalang from the list of dependencies in you crate
has as disadvantage that users that don't have libadalang get errors and might not know which crate they are missing.

[Fabien-Chouteau]

Indeed it's a trade-off.

[mosteo]

Hi @pjljvandelaar. Another possibility worth a try, if the installed versions have project files with the same name as the alire ones, it's to instruct your users to alr pin to them. This will override the regular dependency.

If project file names do change, you could prepare a proxy project that withed the installed versions, and pin to the proxy project (which should have the proper project names).

I haven't tested this particular case, so I'd be interested in knowing if you make it work.

Although, removing the dependencies and setting an environment variable as Fabien suggested is probably less work...

[mosteo]

For this to work you'll need to pin directly the folder containing the project files of each dependency.

[pjljvandelaar]

I wil experiment some more with "C:\GNATPRO\22.1\share\gpr" since
that contains the project files of the dependencies, right?

[mosteo]

Right, and the pin system should detect that as a "raw" project (no manifest, only the project file)

[pjljvandelaar]

Despite that libadalang.gpr contains
for Source_Dirs use ("../../include\libadalang\");
I still get
rewriters_sequence.ads:2:06: error: file "libadalang.ads" not found

Has it something to do with Primary_Source_Dirs? See https://gt3-prod-1.adacore.com/#/tickets/V428-008

[mosteo]

I don't have access to that ticket, sorry.

I'm not sure if there's some way to see the final search paths in use by gprbuild. That could help to ascertain what's happening.