This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Thoughts on reordering the source tree
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Steven Bosscher <stevenb dot gcc at gmail dot com>
- Cc: GCC Mailing List <gcc at gcc dot gnu dot org>
- Date: Fri, 1 May 2009 13:41:40 +0000 (UTC)
- Subject: Re: [RFC] Thoughts on reordering the source tree
- References: <571f6b510905010505r515583cehf5ec2407620b6c12@mail.gmail.com>
On Fri, 1 May 2009, Steven Bosscher wrote:
> - c-* go to gcc/c (including c-common.*, 29 files)
I still suggest using a separate c-family/ directory for those files also
shared with C++. There are some cleanups that need doing of files that
include C headers that shouldn't, and of c-family files that include
C-specific headers but should just include c-family headers.
One cleanup you don't mention is moving all the files built for the target
(libgcc, crt*, libgcov, ginclude/, etc.) to be located under libgcc/,
outside the gcc/ directory altogether. I do not believe this requires
completing the toplevel libgcc transition in other respects (moving all
the configuration and build rules into the libgcc directory); makefile
rules could be adjusted wherever those rules are located, and you can move
most of the files while still having some inclusions of tm.h from
target-side files.
> - driver goes to gcc/driver
What about host-side programs that are neither driver nor part of the
compilers proper (cc1 etc.) - collect2, gcov, mips-tdump, mips-tfile
(maybe others)? (Actually I'd be inclined to suggest deprecating
alpha*-dec-osf[45]* without the GNU assembler so we can get rid of
mips-tdump and mips-tfile. I think we already had consensus to
deprecate/remove gccbug, just no patch to do so.)
It would be nice not only for target files not to use the host-side tm.h
but also for tm.h for compilers proper to be separate from the
configuration for the driver and for these other utilities. But we need
to keep such cleanups separate from moving files rather than forcing
dependencies in either direction.
--
Joseph S. Myers
joseph@codesourcery.com