Re: RFC: Moving C to its own directory

[Alexandre Oliva <aoliva at redhat dot com>]

On Jun  2, 2003, Zack Weinberg <zack@codesourcery.com> wrote:

> Geert Bosch <bosch@gnat.com> writes:
>> On Sunday, Jun 1, 2003, at 15:19 America/New_York, Neil Booth wrote:
>>> Following a brief discussion with rth at the summit, and just
>>> now on IRC, I thought I'd post what the current plan is.
>>> 
>>> 1) Create a directory fe/
>>> 2) Create a directory fe/c/
>>> 3) Move c-specific and C common files, like c-lex.c, there.
>>> 4) Move objc/ to fe/ too.
>> 
>> Can't we just have directories c/ objc/ cp/ java/ etc?
>> I don't quite see what the extra fe/ level buys us.

> Additional structure.

FWIW, I don't think it's worth the hassle.  */config-lang.in should
tell you what is a front-end directory and what isn't.  Changing
current conventions would affect not only GCC per se, but also other
front ends that are drop-ins, like Pascal.  Supporting both means we'd
have yet another incomplete change, so I'd rather keep the current
state of affairs, at least until we use some CVS replacement that
supports renaming directories.

> Farther down the road, people are considering having subdirectories
> for tree and RTL optimizers and "back end" logic

I don't think this really counts as a reason for separating front-ends
into a sub-directories.  We may very well have tree/ and rtl/ as
sub-directories, if we want to, and this won't conflict with anything
unless someone comes up with tree or rtl front-ends.  We may prevent
such a situation by prepending say fe- to front-end directory names,
and me- or so to middle-end files.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer