From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD,
	FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4
X-Received: by 2002:ae9:c106:: with SMTP id
 z6mr102530406qki.285.1561390746080;
        Mon, 24 Jun 2019 08:39:06 -0700 (PDT)
X-Received: by 2002:a9d:6289:: with SMTP id x9mr42469735otk.82.1561390745606;
 Mon, 24 Jun 2019 08:39:05 -0700 (PDT)
Path: 
 eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!m24no660796qtm.0!news-out.google.com!33ni302qtt.0!nntp.google.com!m24no660785qtm.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Mon, 24 Jun 2019 08:39:05 -0700 (PDT)
In-Reply-To: <86e32abe-7c57-4ea1-879e-869464a6a316@googlegroups.com>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=89.20.165.50;
 posting-account=6yLzewoAAABoisbSsCJH1SPMc9UrfXBH
NNTP-Posting-Host: 89.20.165.50
References: <86e32abe-7c57-4ea1-879e-869464a6a316@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <2aa12fd0-dcf6-4b31-9c13-612a359dd731@googlegroups.com>
Subject: Re: gprbuild and package renames (testsuites)
From: briot.emmanuel@gmail.com
Injection-Date: Mon, 24 Jun 2019 15:39:06 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Xref: reader01.eternal-september.org comp.lang.ada:56734
Date: 2019-06-24T08:39:05-07:00
List-Id: <comp.lang.ada>

I don't think you'll be able to run all three testsuites from the same exec=
utable. Instead, you could use a "scenario variable" to configure mode1, mo=
de2 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-speci=
fic object dirs. Then you run all three executables independently.

Things get more interesting when you have multiple projects involved. In th=
is case, that would mean having to duplicate the case statements in all pro=
jects (and things get even more complicated when you want to mock various c=
ombinations -- 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;
=20
   project Postgresql_Mock extends "postgresql.gpr" is
       --  override any file you need
       for Source_Dirs use ("mocks");
   end Postgresql_Mock;

 =20
   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 fr=
equently happens that gprbuild doesn't properly recompile all the files (th=
ough 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