From: Jacob Sparre Andersen on 10 May 2007 15:57 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 10 May 2007 16:31 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 10 May 2007 16:01 > 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 10 May 2007 17:00 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 11 May 2007 03:14
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! |