This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: structuring a front-end subdirectory
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