Re: gprbuild and package renames (testsuites)

[briot.emmanuel@gmail.com]

I don't think you'll be able to run all three testsuites from the same executable. Instead, you could use a "scenario variable" to configure mode1, mode2 and mode3. Some case statements would be used to select which packages are stubs, as well as a mode-specific executable name and likely mode-specific object dirs. Then you run all three executables independently.

Things get more interesting when you have multiple projects involved. In this case, that would mean having to duplicate the case statements in all projects (and things get even more complicated when you want to mock various combinations -- for instance mock postgresql and Kafka for one test, but not mock postgresql in another one).

In the end, the case statement approach doesn't scale really well. We ended up using "extending" and "extending all" projects. For instance:

   project Postgresql is
         ...  --   used to build production executables
   end Postgresql;

   with "postgresql.gpr";
   with "b.gpr";
   project Build is
        ...  --  used to build production executables
   end Build;
 
   project Postgresql_Mock extends "postgresql.gpr" is
       --  override any file you need
       for Source_Dirs use ("mocks");
   end Postgresql_Mock;

  
   with "postgresql_mock.gpr";
   with "b.gpr";
   project Unittest extends all "build.gpr" is
        --  any project imported by build.gpr or b.gpr that was
        --  also importing "postgresql.gpr" will now instead
        --  import "postgresql_mock.gpr" and thus see the mocks
   end Unittest;

This solution is not so easy to setup, and is kind of fragile because it frequently happens that gprbuild doesn't properly recompile all the files (though I could never reproduce systematically and thus report it). In general
this happens when the timestamps of the mocks are similar to the timestamps of
the original files, so by "touch"-ing some files we get around the gprbuild
issues...

Emmanuel