Re: structuring a front-end subdirectory

[Olivier Hainque <hainque at adacore dot com>]

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