This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Moving C to its own directory (was Re: ObjC tree inlining)

Joseph S. Myers wrote:-

> It's established that we only ever use cvs add / cvs remove, and don't do
> anything directly in the repository except for bulk imports of directories
> previously maintained in CVS elsewhere (e.g. libjava).
> What is the exact proposal?  That is, what goes in what directory, and 
> does C become a language that should be named in --enable-languages (and 
> is included in lang_requires for the other language subdirectories?)?

I would propose that we move all C-specific (only c-lang.c I believe),
and C-or-ObjC files to a c/ directory.  I'm thinking of things like
c-decl.c, c-lang.c, c-tree.h, and c-typeck.c.  In the
process they should probably be renamed to remove the "c-" prefix,
with the exception of c-lang.c since that really is C-specific (and
the only such file I believe).

Things common to C++ as well as C/ObjC, like c-lex.c, c-format.c and
c-common.c are debatable, but IMO should go there too.  For clarity, I
would rename those so they have a "common" suffix, e.g. lex-common.c,
fmt-common.c, and common.c (avoiding the 8-3 and 14 issue).  I see
plenty of scope for code that is currently separate becoming more
common in the future, in which case we might create, say,

C is still implicitly enabled in --enable-languages because we still
require it to bootstrap.  It is still special in this sense, but I
would hope we can reduce the C-isms in other parts of the compiler,
e.g. the semantics of trees.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]