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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,d92cd733dc93e4e4 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Newsgroups: comp.lang.ada Subject: Re: Gnat 3.15p @ win-2000 recompiles _all_ internal packages ... References: From: M E Leypold Date: 02 Jun 2006 18:19:53 +0200 Message-ID: <9ik67z1qdy.fsf@hod.lan.m-e-leypold.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Some cool user agent (SCUG) NNTP-Posting-Host: 88.72.226.187 X-Trace: news.arcor-ip.de 1149264885 88.72.226.187 (2 Jun 2006 18:14:45 +0200) X-Complaints-To: abuse@arcor-ip.de Path: g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor-ip.de!news.arcor-ip.de!not-for-mail Xref: g2news2.google.com comp.lang.ada:4650 Date: 2006-06-02T18:19:53+02:00 List-Id: Simon Wright writes: > M E Leypold writes: > > > Actually that is not what happens: Under Debian it works as I > > expected, but under Windows a lot of internal packages are recompiled > > to project-local *.ali and *.o files. It is almost as if gnatmake > > can't see the packages in .../lib/adalib/. > > There was a problem with GNAT 3.16a1 on Windows which might also apply > to 3.15p; it had the amusing symptom that compilations with the -m > (minimal recompile) option ran much more slowly if the compiler was > installed in non-daylight saving time. So the simple fix was to set > the date to July, reinstall, then set the date back. > > The problem was with apparent file timestamps; the installation > process ended up with the file timestamp being an hour out from the > .ali timestamp. Aaah. Yes. There might be something in it: I'll have to recheck the timestamps (I could just touch the *.ali and *.o files in the runtime, couldn't I?) I have some vague memory that the handling of timestamps with regard to daylight saving time under windows was a problem in unison (a file synchronizer written in OCaml). I'm always mystified by occurrences like this: I'd have expected that every operating platform that has time stamps at all would provide a function to get locale independent "newtonian" time from clock or from file time stamps. Probably not. :-). > I think you might be able to just compile Ada.Containers with -gnatg > (-gnatpg? both?) and make the .ali files read-only; put the source and > object/ali files in an adainclude/adalib directory pair somewhere > separate from your main build. Yep. I could. There is another problem with annoying warnings about (presumably missing) finalize methods if the packages are compiled in the Ada.* hierarchy that go away if they are renamed into the AI302.* hierarchy. I have found the message in the GNAT source and I'd guess (but haven't examined the problem thoroughly yet), that this is actually a bug in 3.15p. So it would actually be better if I precompiled Ada.Containers and stored the *.ali and *.o files in an approiate library directory. But: This is not what my original concept intended. My usual setup uses everything that does not come with the operating system as "source library" and the object files are locally remade for every project. That allows me to fix bugs in the libraries when I find them without having to remember to rebuild the library and without having to leave the IDE (emacs + a number of homegrown functions and external utilities). Customers and collaborators just get a selfcontained subset of the cvs files and building the projekt should be as easy as calling 'make all' (no multiple seperate steps). I'd hat to break that concept w/o a good reason. Well -- thanks for your input: I'll have a look into the timestamp issue (not very fast, though) and report back some time. Regards -- Markus