alr install redux: Installation of binary crates

[mosteo]

I'm confident I have now a clear roadmap in my head for what we want and what we may achieve easily. It's documented in the new doc/AEPs file.

This PR lays the foundation, creating the alr install subcommand, and allowing only the installation of binary crates like the ones we already have.

[Fabien-Chouteau]

I think during our last discussion we said we are not going to worry about what can go wrong and just call gprinstall recursively on all the dependencies. Are you moving to something more involved?

I have a couple question on the AEP.

[Fabien-Chouteau]

Why the different versions are installed in sub dirs of lib/? Do you have to change something in the GPR file for that?

What about the installation artifacts? Where are they installed in that case?

   package Install is
      for Artifacts (".") use ("share");
   end Install;

[mosteo]

It seems the libs are installed redundantly in the /lib folder (as a softlink) and in the named subfolders (as the proper file).

I expect that not using an installation name we would lose the ability to uninstall, and the libs will end just in /lib. (I didn't try this.)

I didn't try with Artifacts, either. Will do. If they don't behave as expected with installation names, we can simply drop that and the possibility of uninstallation altogether.

[mosteo]

I've added a couple of more tests to the AEP file. In short, softlinks to libs can be placed where convenient, although LD_LIBRARY_PATH still will be needed, and artifacts still work as expected.

[Fabien-Chouteau]

But then don't you have to set lib dirs of installed libraries in LD_LIBRARY_PATH?

[mosteo]

I expected this to be necessary in any case, unless we override with --lib-subdir so lib softlinks are placed together with executables in bin? Would be acceptable I think.

[Fabien-Chouteau]

That's the kind of "complexity" that we don't want to deal with I would say. How would one know the list of dirs to add in LD_LIBRARY_PATH?

"Build static or deal with the consequences" :)

[mosteo]

Ah, but is just one dir to add, LD_LIBRARY_PATH+=:$HOME/.alire/lib (or bin). I considered that acceptable if someone does want to go the dynamic way.

[Fabien-Chouteau]

Yes one dir that's always the same is easy. My understanding of what is in this PR is that there would be different folders:

 lib/libhello=1.0.0/libhello/
 lib/libhello=1.0.1/libhello/

etc.

[mosteo]

Those would exist too, but there is always a softlink from the single dir we decide to use (created by gprinstall, not even us), e.g.:

lib/libhello.so.1.0.0 --> lib/libhello=1.0.0/libhello/libhello.so.1.0.0
lib/libhello.so.1.0.1 --> lib/libhello=1.0.1/libhello/libhello.so.1.0.1

To summarize, we can have both binaries and links to libraries in a single dir. The actual libraries reside in subdirs. This is all managed by gprbuild. And, as by default we're using static linking, the issue doesn't even arise unless the user forces dynamic linking.

But actually that's not in this PR yet, which only copies binaries in place. We can verify in the follow-up PR I'm preparing that things fall into place as I think.

[Fabien-Chouteau]

That depends on what the developers set in the library GPR file. By default Alire generates a correct GPR, but there's not guaranty people will not change them.

In my opinion we should not care about this case, but it's better to keep it in mind.

[mosteo]

Right, I too was thinking from the POV of our template projects.

[mosteo]

I think during our last discussion we said we are not going to worry about what can go wrong and just call gprinstall recursively on all the dependencies. Are you moving to something more involved?

No, precisely what I found during my latest tests it that that is not only the simplest, but also the best way for us to go.

The use of gprbuild will come in a later PR for regular crates, as that is not necessary for binary crates without project files.