GPS Compiler options

GPS Compiler options

[ldries46]

I'm relatively new to GPS. I'm trying to compile a program but every time I 
compile the program I observe that all units are compiled when I had 
expected that only the unit I had altered would be compiled again. What do I 
have to do to make this work. I alreday have tried all types of building of 
the program. 

Re: GPS Compiler options

[Ludovic Brenta]

ldries46 wrote on comp.lang.ada:
> I'm relatively new to GPS. I'm trying to compile a program but every time I
> compile the program I observe that all units are compiled when I had
> expected that only the unit I had altered would be compiled again. What do I
> have to do to make this work. I alreday have tried all types of building of
> the program.

The bug may be either in gnatmake or in your expectations; this
depends on which unit you change.

If you change a spec, then all specs and all bodies that depend on the
changed spec need to be recompiled.

If you change a generic body, then all specs and bodies that contain
an instantiation of the generic body need to be recompiled (this is
specific to GNAT, which does not share the object code between
insiantiations of a generic).

If you change a file containing a "separate" unit, then the enclosing
unit needs to be recompiled too, because GNAT emits only one object
file containing the enclosing units and all "separate" bodies in it.

We could help you more if you would be more specific about the units
in your program and on which units you changed.

PS. Maybe consider using the gnatmake -m switch ("minimal
recompilation"); you do that by changing the project properties in
GPS. With this option, gnatmake expends more effort trying to
determine which units are still up to date.

--
Ludovic Brenta.

Re: GPS Compiler options

[Dmitry A. Kazakov]

On Fri, 9 Apr 2010 07:15:07 -0700 (PDT), Ludovic Brenta wrote:

> ldries46 wrote on comp.lang.ada:
>> I'm relatively new to GPS. I'm trying to compile a program but every time I
>> compile the program I observe that all units are compiled when I had
>> expected that only the unit I had altered would be compiled again. What do I
>> have to do to make this work. I alreday have tried all types of building of
>> the program.
> 
> The bug may be either in gnatmake or in your expectations; this
> depends on which unit you change.
> 
> If you change a spec, then all specs and all bodies that depend on the
> changed spec need to be recompiled.
> 
> If you change a generic body, then all specs and bodies that contain
> an instantiation of the generic body need to be recompiled (this is
> specific to GNAT, which does not share the object code between
> insiantiations of a generic).
> 
> If you change a file containing a "separate" unit, then the enclosing
> unit needs to be recompiled too, because GNAT emits only one object
> file containing the enclosing units and all "separate" bodies in it.
> 
> We could help you more if you would be more specific about the units
> in your program and on which units you changed.
> 
> PS. Maybe consider using the gnatmake -m switch ("minimal
> recompilation"); you do that by changing the project properties in
> GPS. With this option, gnatmake expends more effort trying to
> determine which units are still up to date.

Also, when the object and ali-files are on a remote server, usually
together with the sources (this is the case at my work), accessed over a
network file system (samba, NFS etc), then if the compiling computer has
the clock unsynchronized with the server, you may get the described effect
(or worse, non-compiled files).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: GPS Compiler options

[sjw]

On Apr 9, 3:26 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> Also, when the object and ali-files are on a remote server, usually
> together with the sources (this is the case at my work), accessed over a
> network file system (samba, NFS etc), then if the compiling computer has
> the clock unsynchronized with the server, you may get the described effect
> (or worse, non-compiled files).

And (experience on a previous project with Solaris NFS) much longer
compilation times.

Re: GPS Compiler options

[Ludovic Brenta]

Dmitry A. Kazakov wrote on comp.lang.ada:
> On Fri, 9 Apr 2010 07:15:07 -0700 (PDT), Ludovic Brenta wrote:
> > ldries46 wrote on comp.lang.ada:
> >> I'm relatively new to GPS. I'm trying to compile a program but every time I
> >> compile the program I observe that all units are compiled when I had
> >> expected that only the unit I had altered would be compiled again. What do I
> >> have to do to make this work. I alreday have tried all types of building of
> >> the program.
>
> > The bug may be either in gnatmake or in your expectations; this
> > depends on which unit you change.
>
> > If you change a spec, then all specs and all bodies that depend on the
> > changed spec need to be recompiled.
>
> > If you change a generic body, then all specs and bodies that contain
> > an instantiation of the generic body need to be recompiled (this is
> > specific to GNAT, which does not share the object code between
> > insiantiations of a generic).
>
> > If you change a file containing a "separate" unit, then the enclosing
> > unit needs to be recompiled too, because GNAT emits only one object
> > file containing the enclosing units and all "separate" bodies in it.
>
> > We could help you more if you would be more specific about the units
> > in your program and on which units you changed.
>
> > PS. Maybe consider using the gnatmake -m switch ("minimal
> > recompilation"); you do that by changing the project properties in
> > GPS. With this option, gnatmake expends more effort trying to
> > determine which units are still up to date.

> Also, when the object and ali-files are on a remote server, usually
> together with the sources (this is the case at my work), accessed over a
> network file system (samba, NFS etc), then if the compiling computer has
> the clock unsynchronized with the server, you may get the described effect
> (or worse, non-compiled files).

I think gnatmake -m corrects this problem. With this option, gnatmake
no longer relies on the timestamps but only on the CRC32 values in
the .ali files.

--
Ludovic Brenta.

Re: GPS Compiler options

[Simon Wright]

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

> I think gnatmake -m corrects this problem. With this option, gnatmake
> no longer relies on the timestamps but only on the CRC32 values in
> the .ali files.

I believe that it first compares the timestamps: if the same, no change,
but if different, does the ali check.

Re: GPS Compiler options

[Ludovic Brenta]

Simon Wright wrote on comp.lang.ada:
> Ludovic Brenta <ludo...@ludovic-brenta.org> writes:
> > I think gnatmake -m corrects this problem. With this option, gnatmake
> > no longer relies on the timestamps but only on the CRC32 values in
> > the .ali files.
>
> I believe that it first compares the timestamps: if the same, no change,
> but if different, does the ali check.

Exactly. And gnatmake will then do the right thing (i.e. not
recompile) if the timestamps are different only because the clocks of
various machines are out of sync.

--
Ludovic Brenta.

Re: GPS Compiler options

[Simon Wright]

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

> Simon Wright wrote on comp.lang.ada:
>> Ludovic Brenta <ludo...@ludovic-brenta.org> writes:
>> > I think gnatmake -m corrects this problem. With this option, gnatmake
>> > no longer relies on the timestamps but only on the CRC32 values in
>> > the .ali files.
>>
>> I believe that it first compares the timestamps: if the same, no change,
>> but if different, does the ali check.
>
> Exactly. And gnatmake will then do the right thing (i.e. not
> recompile) if the timestamps are different only because the clocks of
> various machines are out of sync.

Indeed. But it takes much longer, because it has to open each file; and
this is even worse over a network.

GNAT 3.16a1 on Windows had a wonderful feature where the RTS timestamps
were out by an hour unless you installed in daylight savings time! This
led to opening all the relevant RTS files, every time, every
compilation -- and to an interesting work instruction.