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:5755:: with SMTP id u82mr7047602ita.16.1542874532705; Thu, 22 Nov 2018 00:15:32 -0800 (PST) X-Received: by 2002:aca:4eca:: with SMTP id c193mr172795oib.7.1542874532343; Thu, 22 Nov 2018 00:15:32 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!feeder.erje.net!1.eu.feeder.erje.net!fdn.fr!proxad.net!feeder1-2.proxad.net!209.85.166.215.MISMATCH!z5-v6no27936ite.0!news-out.google.com!v141ni59ita.0!nntp.google.com!z5-v6no27928ite.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 22 Nov 2018 00:15:32 -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: <0d4679d2-30d7-493f-b9fd-688d044e1a4e@googlegroups.com> Subject: Re: GNAT Modification_Time limitation From: briot.emmanuel@gmail.com Injection-Date: Thu, 22 Nov 2018 08:15:32 +0000 Content-Type: text/plain; charset="UTF-8" Xref: reader01.eternal-september.org comp.lang.ada:54872 Date: 2018-11-22T00:15:32-08:00 List-Id: > I'd argue that these are something else on top of individual builds. And > that it is a mistake trying to combine basic building with those > higher-level configuration management things. Not sure about the concepts about you describe. For me, "basic building" is one run of the compiler on one specific file, which always recompiles, no question asked. What we are talking about in this thread a tools at the level of make and gprbuild, that decide what should be compiled, and when. For me, this is thte "higher-level build management part". That includes configuration management, since this tool is also responsible for deciding where the build artifacts (object files, executables,...) should be stored. > > its own set of object files, and each taking 20 or 30 minutes to build > > from scratch. Not realistic for continuous testing. > > You need a faster compiler. :-) :-) I wish I had one. Still, this is compiling 6000 Ada units + C files iin 20 minutes, not too bad (using parallel builds, of course). > Seriously, at least debug vs. production has to be built over from scratch > (at least the way I typically use those). Definitely. And I agree with your conclusion that we need separate builds for every possible combination of environment/switches (debug, production,...) and source files (alternate bodies,...). Disk space is cheaper than our time, though fast SSDs are still not quite as cheap as we would all like. > It's hard to imagine a build taking less than two seconds; certainly not if > a human is involved, and very unlikely even if automated. Don't forget that Lionel's make-like tool and gprbuild are both meant to be language-neutral. Compiling an Ada file in less than 2s is rare nowadays (but possible with very simple files. But compiling a python file takes a few ms, so just looking at timestamps cannot be enough (though when compilation is that fast, it doesn't matter much to redo it more often... > (The Janus/Ada > binder is fairly slow as it removes unreachable subprograms recursively -- Nice feature. With gcc we use link time optimization to achieve the same effect (and more), and that's slow indeed. > COrder (the Janus/Ada compilation order tool that's at the heart of any > builds) has an old /T option that uses file timestamps, but it has not been > recommended for a while. It's faster than the /I option that inspects the > internal timestamps and the source code ('cause it doesn't have to open > hundreds of files and read part of them), but it messes up so often it is > not recommended anymore. (One nice side-effect of /I is that one can simply > delete all of the SYM files to force a rebuild of everything; /T doesn't > always rebuild everything in that case.) One interesting of the TUP builder I mentioned yesterday is that it comes with an optional daemon program, that monitors the changes on the file system (inotify on linux), so that when you start the build it already knows what files have been modified and can start building right away. Saving 10s or more every time I launch gprbuild would be nice ! > In any case, timestamps have their place, but they have to be used > carefully. Seconded. They can be used as a shortcut: the builder can have a mode that says "assume the file was modified if the timestamp has changed, but if the timestamp is the same, check the contents". And then a "minimal recompilation switch" that says "only look at file contents to detect whether file has changed". Emmanuel