[RFC] Installation of binaries and libraries

[mosteo]

As part of the installation/sharing of resources (#948), problems with blind gprinstallation of a build were pointed out:

• Conflicting versions of [static/dynamic] libraries
• Conflicting versions of configurations for the same crate

And I will add:

• Conflicting builds of the same executable

I've been trying to come up with some ideas but it seems all exceedingly complex. A thing I can think of right now (and it's not that simple) is to keep track in the installation prefix of all installed crates, so we allow only installation of one version per crate and prefix. This may be quite limiting, but would at least get rid of all problems (I think). The idea would be to have a kind of hidden root crate that depends on everything, so the build for all installed things is consistent.

For the basic feature of installing executables to a common path it may be enough. I haven't thought through all the details yet.

[Fabien-Chouteau]

I don't have time to look at what the other package managers do, but I would think that cargo has the same kind of constraints.

[mosteo]

I've checked the documentation at https://doc.rust-lang.org/cargo/commands/cargo-install.html and played a bit with the feature and their solution is to make the scope very narrow:

• Only binaries can be installed
• Only one version per binary

Also from this question it seems Rust is heavily biased towards static linking which further removes problems with dynamic library dependencies.

I don't think gprbuild has a way to force-override static build/linking of all projects. We only have the soft convention of the LIBRARY_KIND external. Assuming that's right, I'm inclined to treat an installation prefix like a complete set of dependencies. This way we're sure nothing is broken and any dynamic libraries are in their proper place, and we entirely sidestep this particular can of worms.

The (big?) limitation in this case is that executables with conflicting dependencies couldn't be installed together. However there are other advantages besides avoiding dynamic lib issues, like that we could allow installation of libraries and reuse more (most?) parts of how we manage a regular workspace.

[Fabien-Chouteau]

• Only binaries can be installed

  • Only one version per binary

Sounds good to me.

don't think gprbuild has a way to force-override static build/linking of all projects.

No I don't think so.

I'm inclined to treat an installation prefix like a complete set of dependencies. This way we're sure nothing is broken and any dynamic libraries are in their proper place, and we entirely sidestep this particular can of worms.

I am not sure to understand what you mean here.

[mosteo]

I am not sure to understand what you mean here.

The idea I have in mind is that the installation prefix is kind of a "hidden" regular workspace. So when installing something, we add it as a dependency of the "hidden" root crate and we solve the dependencies of everything as a whole, and so all library dependencies are consistent, even if shared among executables. The addition wrt a regular workspace would be the final gprinstall into the standard prefix locations.

In essence, we would be making a gprinstall of everything in the prefix whenever something is added, instead of compounding separate gprinstalls that I suspect can either fail when some file has to be overwritten, or cause inconsistencies if forcing the installation.

That said, I have only sparsely used gprinstall...

[stephe-ada-guru]

I'm preparing an Alire crate for Emacs Ada mode. It creates a parser executable that requires a parse table (a large plain text file). The executable communicates with Emacs lisp code, which is installed by the Emacs package manager. The communication protocol between the elisp and Ada code includes a version check, so version mismatches are reported; it is up to the user to fix them.

However, the executable simply assumes that a file with the right name in the executable directory is the right parse table file. I could add a version check here, but as long as gprinstall installs both files at the same time, this seems safe enough (this is the way the current install script distributed with the lisp code package works).

The parse table file is built by another executable, provided by the wisitoken crate. Creating that table file could be done in a post-build Alire hook, or in a pre-install Alire hook.

So an "alr install" command that does "pre-install hooks, gprinstall, post-install hooks" is fine for Emacs Ada mode.

[mosteo]

alr install implemented in #1302