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:a6b:b5cb:: with SMTP id e194-v6mr3329835iof.31.1542785471925; Tue, 20 Nov 2018 23:31:11 -0800 (PST) X-Received: by 2002:a9d:286a:: with SMTP id h39mr87590otd.5.1542785471632; Tue, 20 Nov 2018 23:31:11 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.uzoreto.com!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!q69no117319itb.0!news-out.google.com!v141ni55ita.0!nntp.google.com!q69no117318itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 20 Nov 2018 23:31:11 -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> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <62ffa1fb-6733-4f97-ba87-ae3103bfc877@googlegroups.com> Subject: Re: GNAT Modification_Time limitation From: briot.emmanuel@gmail.com Injection-Date: Wed, 21 Nov 2018 07:31:11 +0000 Content-Type: text/plain; charset="UTF-8" Xref: reader01.eternal-september.org comp.lang.ada:54853 Date: 2018-11-20T23:31:11-08:00 List-Id: > I wouldn't claim that the situation is that dire; it seems to be related to > the particular implementation of a particular GNAT feature (project scenario > variables). If you're not implementing something where the source code > location can be changed for a particular build, then timestamps will work > (but you have to remember that they are quite granular). The trick of course is to define what a "build" is in your sentence. If it is one execution of the builder (gprbuild, make,...) then I think it is indeed a reasonable assertion. If however a build is defined to something that amount to "in debug mode, in production mode,..." then of course it might happen that the sources are changed and the timestamp have a timestamp delta of less than 1s (when we generate code for instance). Furthermore, the actual scenario was the following: in the automatic tests, I need to simulate the connection to the database, so that means I need to have support for alternate bodies (but I still compile in debug mode, or production mode,...). Is that still the same "build" ? I would guess it is, but in the end we would end up with literally dozens of "build" types, each with its own set of object files, and each taking 20 or 30 minutes to build from scratch. Not realistic for continuous testing. I spent some time looking around at general builder tools around. Most of them seem to advertise nowadays that they look at file contents, not timestamps. I started from the list at https://en.wikipedia.org/wiki/List_of_build_automation_software, and looked at a few of them. > It also seems to be related in part of source-based compilation (which > necessarily keeps less information between builds). In a Janus/Ada project > (which is very different than a GNAT project -- it's a binary DB-like file > of compilation information), changing the location of a source file would > invalidate the entire entry and essentially delete any existing > compilations. More likely, however, is that a scenario would be set up using > separate project files (most likely using Windows batch files/Unix > shell-scripts to automate), so each would have their own set of compilation > states. That's more or less what gprbuild does in practice. It uses a "distributed database" via the .ALI files, which are found in the object directories, so for best use each "build" should have a different object directories. And we are again hitting the notion of "build". > And it's completely impossible to bind multiple versions of a unit > into a single executable; only one or the other could be selected - That's indeed one of the ways gprbuild could detect the error. To me it is a bug in gprbuild that it allows linking different files for the same unit into the same executable. > somehow some files were compiled against the wrong one, some or all of the > compilation timestamps wouldn't match (which would cause binding failure). timestamps are not reliable enough, especially on modern fast machines. I am pretty sure you will hit a similar issue I had, one day.