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

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

[M E Leypold]

Hi,

I've the following setup(s):

 - GNAT 3.15p at Sarge (Debian 3.1) and at Windows 2000 Professional.
 
 - I'm using Martin Dowies Ada95 port of Ada.Containers (which can be
   found here: http://www.martin.dowie.btinternet.co.uk).

   I didn't want to install Ada.Containers as precompiled packages
   (*.ali- and *.o-Files I mean) since I found some minor buglets in
   the code and want to correct them when I find them.

   Instead I use -I... as switch to gnatmake to point gnat make to the
   source distribution.

 - Of course then Ada.Containers doesn't recompile because its in the
   Ada.* package hierarchy and therefore considered 'internal' by Gnat.

   I therefore also give the switch -a to Gnat, which according to
   gnat_ug should incite gnatmake to

   "Consider all files in the make process, even the GNAT internal
    system files".

   As I understood that, gnatmake should only remake the internal
   packages in this situation if the corresponding *.ali- and
   *.o-Files are not up to date.

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/.

All installed files in .../lib/adalib/ are (as far as I can see) much
younger then the sources in .../lib/adainclude/. So that doesn't seem
to be the reason why things go wrong.

Does anybody here have an idea what I'm missing?

Regards -- Markus





 

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

[Gautier]

Maybe you have to look at:

- the -i switch (did you set it ?), in order to have the .o,.ali files 
replacing the previous ones
- use the -I or better the -aO switch to make GNAT look at the objects 
files
- GNATReg: GNAT 3.15p also look(ed) in the registry for pathes not set 
in ADA_OBJECTS_PATH; perhaps your library path is neither path collection

HTH, Gautier
_______________________________________________________________
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

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

[Gautier]

Maybe you have to look at:

- the -i switch (did you set it ?), in order to have the .o,.ali files 
replacing the previous ones
- use of the -I or better the -aO switch to make GNAT look at the 
objects files
- the read-only attributes of the .ali files
- GNATReg: GNAT 3.15p also look(ed) in the registry for pathes not set 
in ADA_OBJECTS_PATH; perhaps your specific library path is neither 
path collection ?

HTH, Gautier
_______________________________________________________________
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

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

[Ludovic Brenta]

M E Leypold <development-2006-8ecbb5cc8a-REMOVETHIS@m-e-leypold.de> writes:
>    As I understood that, gnatmake should only remake the internal
>    packages in this situation if the corresponding *.ali- and
>    *.o-Files are not up to date.
>
> 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/.
>
> All installed files in .../lib/adalib/ are (as far as I can see) much
> younger then the sources in .../lib/adainclude/. So that doesn't seem
> to be the reason why things go wrong.
>
> Does anybody here have an idea what I'm missing?

From the top of my head: look at the file permissions, and make sure
that the .ali files for the GNAT internal units are read-only for all
users.

-- 
Ludovic Brenta.

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

[M E Leypold]

Gautier <gautier@fakeaddress.nil> writes:

> Maybe you have to look at:
> 

> - the -i switch (did you set it ?), in order to have the .o,.ali files
> replacing the previous ones

Well -- there are previous ones and they appear up to date. I don't
want them to be replaced: I'm quite confused that Gnat thinks it
necessary to recompile the standard library at all.

> - use of the -I or better the -aO switch to make GNAT look at the
>   objects files.

Good idea: I'll try it some time this week. I don't think though, that
Gnat actually doesn't see the standard library in that installation:
It can compile the projects without '-a' well enough (and AFAIR
without recompiling the standard library). If it didn't see the object
files of the standard lib I'd expect the linking step to fail, or
wouldn't it?

> - the read-only attributes of the .ali files

Hm. I don't understand the significance of this, but I'll have a look
in the gnat_ug again and think about it.

> - GNATReg: GNAT 3.15p also look(ed) in the registry for pathes not set
> in ADA_OBJECTS_PATH; perhaps your specific library path is neither
> path collection ?

But wouldn't that mean, that I wouldn't be able to compile _anything_
without '-a'? But I can ...

But thanks -- I'll do more research in the directions indicated.

Regards -- Markus

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

[M E Leypold]

Hi Ludovic,

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> M E Leypold <development-2006-8ecbb5cc8a-REMOVETHIS@m-e-leypold.de> writes:
> >    As I understood that, gnatmake should only remake the internal
> >    packages in this situation if the corresponding *.ali- and
> >    *.o-Files are not up to date.
> >
> > Actually that is not what happens: Under Debian it works as I

> From the top of my head: look at the file permissions, and make sure
> that the .ali files for the GNAT internal units are read-only for all
> users.

Hm. I admit, this is a dedicated build machine and presently the build
process runs as Administrator (not the best practice, I admit). So the
.ali files might be writeable by Admin.

But: In the Gnat users guide I read

  -a
     Consider all files in the make process, even the GNAT internal
     system files (for example, the predefined Ada library files), as
     well as any locked files. Locked files are files whose ALI file is
     write-protected.


I understood 'consider' as: Recompile if not up to date (but not
always). Am I wrong? -- AFAIS my standard library is up to date.

But before asserting more, I'll have to check this thoroughly, lock
down the -ali files and then I'll come back if my problem persists.

Thanks for the help.

Regards -- Markus

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

[Simon Wright]

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.

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.

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

[M E Leypold]

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

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

[Simon Wright]

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

> Simon Wright <simon@pushface.org> writes:

>> 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?)

No, the timestamp in the .ali and the file timestamp have to match.

> 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.

You can use GNAT Project for this sort of thing; for a while we built
AUnit with different options from the rest of the build because of the
numerous style warnings. And our setup is similar to yours (each
developer builds from source).

GPR in 3.15 was quite early, though would probably support this sort
of thing.

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

[Ian Sharpe]

Would the strangeness described in 

http://www.codeproject.com/datetime/dstbugs.asp

(basically Windows having different algorithms for converting between
local time and UTC for NTFS, FAT and stat) cause problems?

-- 
Ian Sharpe                  http://www.sharpe-practice.co.uk/isharpe/

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

[M E Leypold]

Ian Sharpe <igs.net.news@ntlworld.com> writes:

> Would the strangeness described in 
> 
> http://www.codeproject.com/datetime/dstbugs.asp
> 
> (basically Windows having different algorithms for converting between
> local time and UTC for NTFS, FAT and stat) cause problems?

When Simon Wright described the installation problem with 3.16a, I
remembered a timestamp problem which occured in the unison file
synchronizer project. This (the bug I remembered) was exactly the bug
/ glitch / strangeness described in your reference. Thanks for
refreshing my memory :-).

I think, if the Gnat Runtime and the installer handle the filestamps
differently (on applies the necessary corrections, the other don't)
and GNAT is packaged in summer and installed in winter this would
exactly lead to the strangeness described by Simon Wright (which was a
1 hour difference between the internal time stamps of the *.ali files
and the external filesystem timestamps of the same files -- if I
correctly understood Simon Wright's last post).


Regards -- Markus