structuring a front-end subdirectory

structuring a front-end subdirectory

[Olivier Hainque]

Hello,

As part of our Ada front-end maintainership, we (AdaCore) would like
to introduce a subdirectory of 'ada' where we would relocate all the
files implementing the Ada-front-end/GCC interface (the "gigi" sources
for the internal GNAT/GCC tree interfacing, plus the build
infrastructure bits: Make*.in and config-lang.in).

This would be a first step in setting up a generally clearer
organization of our sources and would help us move our internal trees
from cvs to svn, which we are working on these days to enhance our
patch submission/integration process.

In our current experimental setups, only very few and simple changes
to the language independant sources are necessary (one for sure, maybe
two, depending on a choice to make), not at all Ada specific so of
possible use to other front-ends.

Before proceeding with a formal patch submission, we would appreciate
feedback on the intent first and would be very happy to provide more
details if need be, so ...

Comments warmly welcome,

Many thanks in advance,

Olivier

Re: structuring a front-end subdirectory

[Joseph S. Myers]

On Fri, 9 Nov 2007, Olivier Hainque wrote:

> As part of our Ada front-end maintainership, we (AdaCore) would like
> to introduce a subdirectory of 'ada' where we would relocate all the
> files implementing the Ada-front-end/GCC interface (the "gigi" sources
> for the internal GNAT/GCC tree interfacing, plus the build
> infrastructure bits: Make*.in and config-lang.in).

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.

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).

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

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: structuring a front-end subdirectory

[Olivier Hainque]

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

Re: structuring a front-end subdirectory

[Paolo Bonzini]

>  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.

Would it be possible to add a --enable-small option to libada, which 
would enable compilation of the subset used by GNAT?  Then, one could 
make libada build twice: as a host module with --enable-small, and as a 
target module without the option.


>   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.

Could you please outline the final "look" of the filesystem?  It would 
seem to me that if everything was moved to libada, this would not be 
necessary anymore.  If you need this as a stopgap measure, it's fine by 
me but I would like a comment in configure.ac saying that this is bound 
to disappear and should not be used by other language front-ends.

In this case, by the way, the gengtype changes would also be less 
necessary, and I could approve the configure.ac patch myself (note that 
I have not finished reviewing it, so this is not --yet-- an approval).

Paolo

Re: structuring a front-end subdirectory

[Paolo Bonzini]

>  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.

Would it be possible to add a --enable-small option to libada, which 
would enable compilation of the subset used by GNAT?  Then, one could 
make libada build twice: as a host module with --enable-small, and as a 
target module without the option.


>   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.

Could you please outline the final "look" of the filesystem?  It would 
seem to me that if everything was moved to libada, this would not be 
necessary anymore.  If you need this as a stopgap measure, it's fine by 
me but I would like a comment in configure.ac saying that this is bound 
to disappear and should not be used by other language front-ends.

In this case, by the way, the gengtype changes would also be less 
necessary, and I could approve the configure.ac patch myself (note that 
I have not finished reviewing it, so this is not --yet-- an approval).

Paolo

Re: structuring a front-end subdirectory

[Olivier Hainque]

Hello Paolo,

Paolo Bonzini wrote:
> Would it be possible to add a --enable-small option to libada, which 
> would enable compilation of the subset used by GNAT?  Then, one could 
> make libada build twice: as a host module with --enable-small, and as a 
> target module without the option.

 Humm, maybe. We'll have to think about it when considering the other
 candidate structural enhancements. Thanks for the suggestion.

> >  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.
> 
> Could you please outline the final "look" of the filesystem?

 Sure. The idea for this first step is to separate the components
 participating in the integration with GCC. We would just create a, say,
 ada/gcc-interface subdirectory and move

    Make-lang.in     # build infrastructure bits
    Makefile.in
    config-lang.in

    ada-tree.def     # internal compiler bits
    ada-tree.h
    ada.h
    cuintp.c
    decl.c
    deftarg.c
    gigi.h
    lang-specs.h
    lang.opt
    misc.c
    targtyps.c
    trans.c
    utils.c
    utils2.c"

 there.

> It would seem to me that if everything was moved to libada, this
> would not be necessary anymore.

> If you need this as a stopgap measure, it's fine by me but I would
> like a comment in configure.ac saying that this is bound to
> disappear and should not be used by other language front-ends.
 
 This really is not intended as stopgap measure.

 Besides our move to svn, a primary goal of the suggested change
 is to move this set of sources out of a more general grabbag, to
 clarify their specific purpose and simplify the grabbag, which in
 turn might make further reorgs easier.

 I think moving them into libada would defeat this purpose.

> In this case, by the way, the gengtype changes would also be less
> necessary, and I could approve the configure.ac patch myself (note that
> I have not finished reviewing it, so this is not --yet-- an approval).

 Thanks much for your feedback,

 Olivier

Re: structuring a front-end subdirectory

[Paolo Bonzini]

 >> It would seem to me that if everything was moved to libada, this
 >> would not be necessary anymore.
 >
 >  Besides our move to svn, a primary goal of the suggested change
 >  is to move this set of sources out of a more general grabbag, to
 >  clarify their specific purpose and simplify the grabbag, which in
 >  turn might make further reorgs easier.
 >
 >  I think moving them into libada would defeat this purpose.

Sorry, I wanted to write "everything related to the Ada RTS".  Of course 
Gigi is not going to be moved into libada.

Paolo

Re: structuring a front-end subdirectory

[Olivier Hainque]

Paolo Bonzini wrote:
> > It would seem to me that if everything was moved to libada, this
> > would not be necessary anymore.

> Sorry, I wanted to write "everything related to the Ada RTS".

 Oh, I see.

> Of course Gigi is not going to be moved into libada.

 Right :-)

 And even if "everything related to the Ada RTS" was moved to libada,
 we believe extracting gigi + gcc build bits out of the rest would still
 be an improvement of our sources organization.

 We are suggesting this first (now), because it is a much simpler step to
 make, we are ready for it, and it would help our maintainership.

 Olivier