What's the best way to acheive this with alire?

A project structure like:

proj/
  src/
    root.ads
  lib1/
    src/
      root-lib1.ad[sb]
  lib2/
    src/
      root-lib1.ad[sb]
  ...
  libn/
    src/
      root-libn.ad[sb]
  app/
    src/
      root-app.adb

they’re all related and I don’t really want to split them up so they’re all separate.

Ah, it is an interesting issue not of Alire specifically but of all hobby ( :grinning:) version control systems built around individual files rather than projects.

If you have a dependency of projects like:

   A
   |
   B
   |
   C

then you cannot have a stable folder structure on the disk or in the file database that remains invariant on the project view. When you map C, it is

current project (C)
   bin/
      C's executables
   src/
      C's sources
   obj/
      C's artifacts

But when you map B, it becomes:

current project (B)
   bin/
      B's executables
   src/
      B's sources
   obj/
      B's artifacts
   C/
      bin/
         C's executables
      src/
         C's sources
      obj/
         C's artifacts

Like your case illustrates when libn folders slip one level down rather than stay on top. You do not want this! Because in effect, you could not run B when C is a dynamic library. B’s bin/ does not contain C’s bin/. The gpr files of C are no longer valid for B. If you change the gpr file for this structure, then it will be different from the production/release bin/. Worse, they will not for the view of the project A! And you have a huge problem that what you test and debug is not the production/release!

The situation becomes even worse in presence of diamond:

      A
     / \
    B   C
     \ /
      D

because D becomes mapped twice when A is viewed.

When I designed a project management system on top of Perforce (now Perforce Helix Core), I flattened the folder structure upon project check out. The best way were of course to have a virtual file system avoid copying files from Perforce, but copying worked fast enough. The top project was read-write, the other project read-only. So the structure was always like this:

bin/      --- all executable artifacts (applications and dynamic libraries
   windows/
      x86_64/
   linux/
      x86_64/
      armhf
   vxworks
      i368/      
proj/   current project
   src/
   obj/
      windows/
         x86_64/
      linux/
         x86_64/
         armhf
      vxworks/
         i368/      
lib1/   -- a library project the current project depends on directly or indirectly
   src/
   obj/
      windows/
         x86_64/
      linux/
         x86_64/
         armhf/
      vxworks/
         i368/      
lib2/
   src/
   obj/
      windows/
         x86_64/
      linux/
         x86_64/
         armhf
      vxworks/
         i368/      

With this I could run all projects, all tests, debug any project having same gpr files.

I have no hope Alire would ever capable of anything close this, but just saying…

I suppose you mean project, lib1, lib2, … libn, app are alire crates. I would just use pins.

2 Likes