Re: organizing deep source trees with child packages

["Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr>]

Le Fri, 14 Oct 2011 03:44:21 +0200, Randy Brukardt <randy@rrsoftware.com>  
a écrit:
> It wouldn't break the Ada semantics, but it would make it a lot harder  
> for
> build tools and the like to function. (Especially simple tools like
> "find"/"grep".)
I don't see an example rigth away, but I still trust this argument.

> And in any case, the solution for "overlong file names" is
> to use shorter ones! There's no law (either in GNAT or Ada) requiring  
> anyone
> to use 50 character file names.
But this is nicer to give the file the exact same name as the unit it  
contains, and with child packages, you easily reach long name (ans many  
files in a single directory).

> Indeed, most of my Janus/Ada work still uses 8.3 file names:  
> "J2Code_E.Ads",
> for example. The actual package name is quite a bit longer. Janus/Ada  
> needs
> only to be told once about the correspondence between package names and  
> file
> names
Seems good. Instead of patching GNAT to make it use another convention, a  
tool could automatically generate a series of “for Spec ("Unit") use  
"Path";” and “for Body ("Unit") use "Path";” and put these in the GPR file  
or even preferably a GPR file included in a master GRP file.
For reference, see:  
http://www.adacore.com/wp-content/files/auto_update/gnat-unw-docs/html/gnat_ugn_12.html#SEC130
This way, anyone can use any directory and file name layout he/she wish  
(and don't tell anyone if he/she prefer nested directories :-P ).

> -- either by compiling the file manually or telling the build tool the
> name when asked. After that, Janus/Ada remembers the file names in the
> project files and does not need to told again (unless of course you  
> decide
> to make a fresh start with your projects and delete the old file).
I like this idea of an interactive configuration :) Was thinking about a  
similar thing some days ago, for another purpose.

-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
Java: Write once, Never revisit