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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a24:7445:: with SMTP id o66-v6mr5060720itc.20.1542822236763; Wed, 21 Nov 2018 09:43:56 -0800 (PST) X-Received: by 2002:aca:4eca:: with SMTP id c193mr130727oib.7.1542822236465; Wed, 21 Nov 2018 09:43:56 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.uzoreto.com!news.muarf.org!nntpfeed.proxad.net!proxad.net!feeder1-2.proxad.net!209.85.166.216.MISMATCH!q69no307598itb.0!news-out.google.com!v141ni100ita.0!nntp.google.com!q69no307597itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 21 Nov 2018 09:43:56 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=176.130.29.212; posting-account=6yLzewoAAABoisbSsCJH1SPMc9UrfXBH NNTP-Posting-Host: 176.130.29.212 References: <0577e947-d691-4b81-aca6-b2e86bbef634@googlegroups.com> <04221674-95d8-4d4a-8743-42877b13eead@googlegroups.com> <62ffa1fb-6733-4f97-ba87-ae3103bfc877@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: GNAT Modification_Time limitation From: briot.emmanuel@gmail.com Injection-Date: Wed, 21 Nov 2018 17:43:56 +0000 Content-Type: text/plain; charset="UTF-8" Xref: reader01.eternal-september.org comp.lang.ada:54866 Date: 2018-11-21T09:43:56-08:00 List-Id: > 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.