From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,4c019ad9cc913bbe X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-09-18 14:18:03 PST Newsgroups: comp.lang.ada Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!uunet!sea.uu.net!ash.uu.net!world!news From: Robert A Duff Subject: Re: The Dreaded "Missing Subunits" Sender: news@world.std.com (Mr Usenet Himself) Message-ID: Date: Wed, 18 Sep 2002 21:17:44 GMT References: <1b585154.0209121449.ef12609@posting.google.com> <3D819EE7.3A69E5EB@praxis-cs.co.uk> NNTP-Posting-Host: shell01.theworld.com Organization: The World Public Access UNIX, Brookline, MA X-Newsreader: Gnus v5.7/Emacs 20.7 Xref: archiver1.google.com comp.lang.ada:29134 Date: 2002-09-18T21:17:44+00:00 List-Id: Emmanuel Briot writes: > Robert A Duff writes: > > > >...Have a look in the documentation at pragma > > > Source_File_Name, which provides handling for any possible naming scheme you > > > can conceive. > > > > This is also of course wrong. The patterns supported by the pragma are > > fairly limited, but I can "conceive" of many things. For example, if > > you want to put all main procedures in files with a certain pattern, it > > doesn't really work. > > Have a look at the more recent versions of GNAT (I don't know if the full > support was already in 3.14p or was added later, although I think it was > already there in 3.14p) for the project files. I don't know. Project files are in 3.14p, but I don't know about "full support". Please tell us what project files can do. > Also have a look at pragma Source_File_Name, where you associate a unit name > with *any* file name you want. There is no notion of naming scheme, since you > can use a different one for each unit and even for specs and bodies for a given > unit. The form of pragma Source_File_Name that lists all the compilation units and their file names is useless, in my opinion, unless there's an automatic way to generate them (as you say below). There is also a form of pragma Source_File_Name that takes a *pattern*, which is sufficient to make GNAT understand, for example, the Rational file-naming convention. That's useful, but as I said, it's not very general. For example, I don't think GNAT will allow multiple compilation units in one file. That's rarely a good idea, but sometimes useful. For example, I would like to put package Ada.Text_IO and the renaming as Text_IO in the same file. For another example, small test programs should usually go all in one file, even when they contain several compilation units. > Of course, it used to be a pain to generate these pragma Source_File_Name by > hand. There is now a tool called gnatname that will scan your source > directories to generate the pragmas directly. The gnatname command does not exist in 3.14p. I would consider this a good solution only if it's fast enough to run it automatically *every* time I do a build (e.g. the Makefile would do "gnatname" followed by "gnatmake"). Is gnatname smart enough to re-scan only those files that have changed (or have newly been created) since the last time I ran gnatname? And to delete whatever information is associated with files I have deleted (or renamed) since the last time I ran gnatname? If not, I suspect it's too slow for large bodies of code. Anyway, this all seems rather convoluted. Why can't the compiler/builder automatically determine which compilation units are in which files? Why is a separate tool needed? And a separate file of pragmas Source_File_Name to maintain? Furthermore, none of this mumbo-jumbo would be necessary at all, if only all Ada compilers agreed on the file naming convention. (I must admit, that wasn't easy in the days when operating systems had unreasonable limits on file names (like only one dot, or only 8 characters). Are those bad-old-days over?) I also admit that C has it easy in this regard, since it has no proper notion of "module" separate from source file. > So any naming scheme is supported, and yes, this is a challenge :-) - Bob