Re: Gnat 3.15p @ win-2000 recompiles _all_ internal packages ...

[M E Leypold <development-2006-8ecbb5cc8a-REMOVETHIS@m-e-leypold.de>]

Simon Wright <simon@pushface.org> writes:

> M E Leypold <development-2006-8ecbb5cc8a-REMOVETHIS@m-e-leypold.de> 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