From: Jacob Sparre Andersen on
Stefan Bellon <sbellon(a)sbellon.de> writes:
> Ludovic Brenta wrote:
>> Stefan Bellon writes:

>> > But timestamps are considered as well. If you touch a file
>> > without modifying it otherwise, it triggers a recompilation.
>>
>> Not in my experience. Changing the timestamp causes a
>> recalculation of the checksum, that's all. Even after adding
>> whitespace or pretty-printing the file, there is no recompilation.
>
> Hmmmm:
>
> bellonsn(a)cube$ gnatmake foo.adb
> gnatmake: "foo" up to date.
> bellonsn(a)cube$ touch foo.adb
> bellonsn(a)cube$ gnatmake foo.adb
> gcc -c foo.adb
> gnatbind -x foo.ali
> gnatlink foo.ali

I suspect that the difference in your experience is that Ludovic keeps
the "-m" flag among his default flags for "gnatmake".

Try:

gnatmake -m foo.adb
touch foo.adb
gnatmake -m foo.adb

Greetings,

Jacob
--
"There are two ways of constructing a software design. One way is to
make it so simple that there are obviously no deficiencies. And the
other way is to make it so complicated that there are no obvious
deficiencies." -- C. A. R. Hoare
From: Simon Wright on
Stefan Bellon <sbellon(a)sbellon.de> writes:

> Ludovic Brenta wrote:
>
>> Stefan Bellon writes:
>
>> > But timestamps are considered as well. If you touch a file without
>> > modifying it otherwise, it triggers a recompilation.
>>
>> Not in my experience. Changing the timestamp causes a recalculation
>> of the checksum, that's all. Even after adding whitespace or
>> pretty-printing the file, there is no recompilation.
>
> Hmmmm:
>
> bellonsn(a)cube$ gnatmake foo.adb
> gnatmake: "foo" up to date.
> bellonsn(a)cube$ touch foo.adb
> bellonsn(a)cube$ gnatmake foo.adb
> gcc -c foo.adb
> gnatbind -x foo.ali
> gnatlink foo.ali

This is the gnatmake -m flag:
if the timestamp hasn't changed: do nothing
elif the semantic content of the file hasn't changed: do nothing
else: recompile

From: Duncan Sands on
> Why not play on a C generator for the Ada language ?

I have one! I'm porting the GNAT Ada f-e to LLVM
(http://llvm.org/), which replaces the gcc code
optimizers with those of LLVM. LLVM has a C backend
which turns its IR into C. So you can put Ada in and
get C out. Unfortunately the C is not always compilable.
For example, if you compile an instance of GNAT.Table with
Natural as the index type, in the C you end up with the
declaration of a very big C array, corresponding to
Big_Table_Type. This array is rejected by the gcc C
compiler as too big. Still, it works most of the time.

Ciao,

Duncan.
From: Pascal Obry on
Duncan Sands a �crit :
>> Why not play on a C generator for the Ada language ?
>
> I have one! I'm porting the GNAT Ada f-e to LLVM
> (http://llvm.org/), which replaces the gcc code
> optimizers with those of LLVM. LLVM has a C backend
> which turns its IR into C.

Interesting, I'll probably have a look at some point. Thanks.

Pascal.

--

--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
From: Gautier on
Lucretia:

> Also, allowing multiple compilation units in the same file can be
> problematic, e.g.
>
> package one is ...;
> package two is ...;
> procedure three is ...;
> package body one is ...;
> package body two is ...;
>
> What if the body of one or two require the subprogram three? Is this a
> form of forward declaration? Would interleaving specs and body's cause
> problems? Probably.

Most Ada compilers allow multiple compilation units in the same file.
They are just treated the same way as if they were each in its file.
It would be surprising if this was not described somewhere in the Manual...
In your example, three is not visible by the body of one or two.

package one is procedure z; end;
package two is procedure z; end;
procedure three is begin null; end;
package body one is procedure z is begin null; end; end;
package body two is procedure z is begin three; end; end;

ObjectAda says to that:
multipack: Error: line 5 col 44 LRM:4.1(3), Direct name, three, is not
visible, Ignoring future references

conversely...

package one is procedure z; end;
package two is procedure z; end;
procedure three is begin null; end;
package body one is procedure z is begin null; end; end;
with three;
package body two is procedure z is begin three; end; end;

compiles fine.
And yes you can put others specs after bodies, just a spec of a package after
its body seems not ok:

package body one is procedure z is begin null; end; end;
package one is procedure z; end;

multipack: Error: line 1 col 15 LRM:7.2(4), corresponding package spec not
found, continuing

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

NB: For a direct answer, e-mail address on the Web site!
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9
Prev: JGNAT - HTML generation
Next: GtkAda Tree_View properties