This is the mail archive of the
mailing list for the GCC project.
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, c-parse.in 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.