GNATing ada files with the wrong extensions.

GNATing ada files with the wrong extensions.

[Dale Pennington]

This is for you GNAT gurus out there.

I have a set of files using the extension scheme of a different Ada compiler
(*.1.ada, *.2.ada), but I desire to build them with GNAT (In fact the folks
who delivered them to us make their final build with GNAT, just not for the
platform we are using). Now to get GNAT to work I can see 2 alternatives :

1) run all the source code through GNATCHOP (or just a big rename script) to
get the GNAT naming convention.

2) create a gnat.adc file and fill it with a zillion Source_File_Name
pragma's.

For reference I am using 3.13p at this time, and have read the docs. I was
kinda hoping that there was acutally a method to tell GNAT to treat .1.ada
as the same as .ads and .2.ada as the same as .adb.

Am I missing something obvious, or are 1 and 2 my only options (and if so,
has anyone generated a godd script to perform #2) ?

Thanks,

Dale Pennington

Re: GNATing ada files with the wrong extensions.

[Ted Dennison]

In article <GIHGrs.Gnt@news.boeing.com>, Dale Pennington says...
>2) create a gnat.adc file and fill it with a zillion Source_File_Name
>pragma's.
>
>For reference I am using 3.13p at this time, and have read the docs. I was
>kinda hoping that there was acutally a method to tell GNAT to treat .1.ada
>as the same as .ads and .2.ada as the same as .adb.

Hmmmm. That seems simple enough, it ought to be worth attempting to put in when
the sources make it to the GCC baseline one fine day. 

But you do realise that there is more to the convention than that, don't you?
For instance, everything has to have the same name as the unit name. Also, you
have to use "-" to replace the dot in child packages and separates. If you have
files from another system that was library based instead of source based, odds
are you have some files that don't quite match their unit names.

>Am I missing something obvious, or are 1 and 2 my only options (and if so,
>has anyone generated a godd script to perform #2) ?

I made a script to do #2 once, but not from the method you used. It instead used
the AdaMagic-style ada.lib and unit.map files. At the time, I discovered that
Gnat had trouble with large amounts of pragma Source_File_Name's, but that was
years ago. It ended up being easier to just browbeat everyone into using Gnat's
naming convention. :-(

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: GNATing ada files with the wrong extensions.

[Mark Johnson]

Dale Pennington wrote:

> 1) run all the source code through GNATCHOP (or just a big rename script) to
> get the GNAT naming convention.
>
> 2) create a gnat.adc file and fill it with a zillion Source_File_Name
> pragma's.
>
> For reference I am using 3.13p at this time, and have read the docs. I was
> kinda hoping that there was acutally a method to tell GNAT to treat .1.ada
> as the same as .ads and .2.ada as the same as .adb.
>
> Am I missing something obvious, or are 1 and 2 my only options (and if so,
> has anyone generated a godd script to perform #2) ?
>

No, nothing obvious for 3.13p. We have a large application as well - a couple
million lines of code developed under Apex. Yes, we have a script that does the
generation of source file name pragmas, one per directory. We have another
script that assembles all of them into a monster file in the build directory.
We don't use either much any more, but I could probably send you a copy.

With the supported 3.14, we changed from #2 (big gnat.adc) to a two liner that
basically is...
  pragma Source_File_Name (Spec_File_Name => "*.1.ada");
  pragma Source_File_Name (Body_File_Name => "*.2.ada");
This works well for ALMOST all our code. We do have a couple vendors that
provided files in GNAT naming conventions - what a pain.

I could suggest alternative #3 - get a support contract from GNAT. [I know
you'll like that suggestion Robert...]

The new version of the compiler fixes this as well as lays in the framework for
significant improvements for defining "a project". Part of the project stuff
takes care of different naming conventions, directory structures, use of
environment variables, and so on.
 --Mark
(not an employee of ACT - but a user of their support)