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: Richard Guenther <richard dot guenther at gmail 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 21:31:59 +0200
- Subject: Re: [RFC] Thoughts on reordering the source tree
- References: <571f6b510905010505r515583cehf5ec2407620b6c12@mail.gmail.com>
On Fri, May 1, 2009 at 2:05 PM, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
> Hello,
>
> The GCC source tree is getting really big. ?We currently have in gcc/:
>
> - 337 .c files
> - 171 .h files
>
> Personally, I think the source tree is quite a mess, the way it is
> now. ?A long time ago (I can't find the threads involved) there was
> some discussion about re-ordering the source tree a bit.
>
> Now that GCC uses subversion, we can move files around without
> destroying the file revision history, right? And we are in stage1, the
> perfect time for Big Changes like re-ordering the source tree.
>
> Thoughts on what the source tree could look like (crude, eventual
> re-ordering is of course a pre-file decision):
> - c-* go to gcc/c (including c-common.*, 29 files)
Agreed.
> - *.h go to gcc/include
Ugh. I don't like this, nor ...
> - ipa-* go to gcc/ipa-opt/ipa
> - tree-* go to gcc/gimple-opt/
> - RTL optimizations (fwprop, see, gcse, loop-*, etc.) go to gcc/rtl-opt/
> - CFG related stuff (cfg*, dominance.c, etc.) go to gcc/cfg
> - plugin* go to gcc/plugin/
> - ira*, sched-*, reload*, final.c, etc. (low level stuff) goes to
> gcc/cg (code generation)
... all the above. At least do not start with this.
> - driver goes to gcc/driver
This is more sensible, likewise the suggestion to move the build tools
(gen*) to a different place.
> - basic intermediate language support stays in gcc/ or goes to gcc/ir,
> or gcc/tree & gcc/rtl, etc.
>
> Thoughts&comments? ?Are there any basic problems/reasons that make
> this kind of change impossible/undesirable at this time?
Branches will get confused. SVN does not really track file moves. So
I think this is not a stage1 but more a stage3 thing.
It also will make grepping even more painful than it is now (remember
that ada change to introduce a 3rd directory level here ...).
I would rather appreciate cleaning up what is in what file (to the extent
to split existing files), than to get even more confusion if I have to think
if stuff might be in ipa/ or ir/ or tree/ ...
Richard.