Hello Joseph,

Joseph S. Myers wrote:
> If moving files, I'd encourage moving the sources built from the libada/ 
> and gnattools/ toplevel directories to be physically located in those 
> directories (or subdirectories of them) as far as possible, as one step in 
> the rearrangement.

> I don't however know how much dependence there might be between
> these sources and the compiler sources that would make such a move
> difficult.

 A number of these sources are indeed shared (some compiler sources
 are used by the library and/or some tools) and moving them is not
 straightforward.

 We are however planning to rearrange things in this area as well and
 much appreciate your suggestions.

 The set of "gcc interface" files is easier to handle and moving it
 would really help our transition to svn in the short term, so we
 decided to start there.

 The two changes in the common infrastructure we have are:

  1) Add a new "gcc_subdir" variable in config-lang.in. When set, configure
     looks for a complete config-lang.in, makefile fragments (Make-lang.in),
     lang tree files, ... in $(srcdir)/<lang_name>/<gcc_subdir>. When not
     set it looks in $(srcdir)/<lang_name> as usual.

  2) adjust gengtype not to reflect the extra subdir in the names of
     the files it generates.

     This is probably not technically mandatory. We just thought it
     would be nice to leave the gt filenames untouched (only dependant on
     the language name).

 The patches are short and we would be happy to submit them if the
 approach is deemed acceptable.
 
> Also note that, as described in gcc/doc/sourcebuild.texi, having 
> gcc/ada/Makefile.in is deprecated, so I hope the rearrangement will 
> eventually make it possible to eliminate this deprecated file (the only 
> language remaining with its own Makefile.in).

 We would be very happy not to have to maintain this one any more :)

 We're not quite there yet, unfortunately, but keep this as another
 target improvement in mind.

> In any case, files should be moved with "svn mv" so that the history is 
> properly maintained.

 Indeed. Thanks much for your feedback,

 Olivier

Reply via email to