comp.lang.ada
 help / color / mirror / Atom feed
From: briot.emmanuel@gmail.com
Subject: Re: GNAT Modification_Time limitation
Date: Wed, 21 Nov 2018 09:43:56 -0800 (PST)
Date: 2018-11-21T09:43:56-08:00	[thread overview]
Message-ID: <f0ddbc5d-d56c-4856-8755-3d6771cfa800@googlegroups.com> (raw)
In-Reply-To: <lyefbecp4v.fsf@pushface.org>

> Ideally, each distinct set of scenario variable values should have its
> own object directory. Will take a lot of time for the initial
> compilations, of course.

That's actually more than that. We already use the above (and indeed we have like 5 or 6 major
scenarios, thankfully we do not compile quite all the possible combiinations).

But in the context of tests, we use extending projects to override some of the sources (for instance
so that we do not have to actually have a database running). The test project itself is an extending-all.

So if you have the simple case:
     a.gpr imports b.gpr imports c.gpr imports d.gpr

and need to substitute a body for a file c.adb in C. you then extend that project, and make a2.gpr an
extending-all project, thus we now have:

     a.gpr imports b.gpr imports c.gpr imports d.gpr
      |
     a2.gpr imports b.gpr imports c2.gpr imports d.gpr

The scenario variables have not changed, so b's objects will go in the 'obj-production' directory
as before, for instance. But in fact, some of object files now depend on that alternate body of
c.adb. If you had some inlined subprograms in c.adb (using -gnatn), then part of their code is
in b.o.

In the common (and optimistic) case where c.adb has a different timestamp from before, b.o
will be recompiled and all is fine.

If c.adb has the same timestamp as the original file (because, hey, git does what it wants),
gprbuild doesn't notice the change in c.adb, so doesn't recompile b.o, and when we link the
executable we go some case from the old c.adb (the inlined code).

This is why just checking the timestamp is not (cannot) be good enough.

Ideally, we should try and use a different object directory here (though the scenario is the
same), but I don't know how to do that (b.gpr hasn't changed, thanks to the extend-all project).

And if you add to the original 5 scenario variables another case where you can potentially
mock any number of project, you end up with way too many combinations of object directories,
my disk would not be big enough I think.


  reply	other threads:[~2018-11-21 17:43 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-19 22:56 GNAT Modification_Time limitation Lionel Draghi
2018-11-20  0:47 ` Shark8
2018-11-20  1:33   ` Keith Thompson
2018-11-20  1:33 ` Keith Thompson
2018-11-20 23:32   ` Randy Brukardt
2018-11-21  8:23     ` Dmitry A. Kazakov
2018-11-20  8:08 ` briot.emmanuel
2018-11-20 11:57   ` Lionel Draghi
2018-11-21  7:40     ` briot.emmanuel
2018-11-21 11:16       ` briot.emmanuel
2018-11-21 19:13         ` Lionel Draghi
2018-11-21 19:02       ` Lionel Draghi
2018-11-21 19:48         ` Simon Wright
2018-11-21 22:14           ` Lionel Draghi
2018-11-20 23:53   ` Randy Brukardt
2018-11-21  7:31     ` briot.emmanuel
2018-11-21 14:38       ` Shark8
2018-11-21 17:32       ` Simon Wright
2018-11-21 17:43         ` briot.emmanuel [this message]
2018-11-21 23:34       ` Randy Brukardt
2018-11-22  8:15         ` briot.emmanuel
2018-11-26 23:45           ` Randy Brukardt
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox