This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: dragonegg in FSF gcc?
- From: Ian Lance Taylor <iant at google dot com>
- To: "Weddington\, Eric" <Eric dot Weddington at atmel dot com>
- Cc: Manuel LÃpez-IbÃÃez <lopezibanez at gmail dot com>, "Dave Korn" <dave dot korn dot cygwin at googlemail dot com>, "Jack Howarth" <howarth at bromo dot med dot uc dot edu>, "Steven Bosscher" <stevenb dot gcc at gmail dot com>, "Duncan Sands" <baldrick at free dot fr>, <gcc at gcc dot gnu dot org>
- Date: Mon, 12 Apr 2010 15:41:01 -0700
- Subject: Re: dragonegg in FSF gcc?
- References: <g2h6c33472e1004120727yff64b19auea2b7e44d0eb4249@mail.gmail.com> <258DDD1F44B6ED4AAFD4370847CF58D50A5D3E17@csomb01.corp.atmel.com>
"Weddington, Eric" <Eric.Weddington@atmel.com> writes:
>From my perspective (and someone correct me if I'm wrong) it is
>easier for LLVM to do such marketing and focus on usability details
>because they seem to have a central driver to the project, whether
>person/group (founder(s)/champion(s)). GCC is, what I would call,
>aggressively decentralized; Who would do such marketing? Who decides
>what marketing to do? Who decides the usability details? Who would
>work on it? GCC is the epitome of the saying "If you want something
>done, do it yourself." There is no central authority who can, or
>will, make a decision about this. There is a Steering Committee for
>GCC, but as they keep saying at the GCC Summits, their power and
>scope is very limited.
Having a central driver would certainly help--though only to the
extent that anybody listened.
I have seen people complain that the gcc developers are ornery and
difficult to work with. I've been reading the mailing lists with that
in mind, and I actually don't see that very much. However, it only
takes a very small number of mean-spirited messages to give that
impression. What I do see is that relatively few gcc developers take
the time to reach out to new people and help them become part of the
community. I also see a lot of external patches not reviewed, and I
see a lot of back-and-forth about patches which is simply confusing
and offputting to those trying to contribute. Joining the gcc
community requires a lot of self-motivation, or it takes being paid
enough to get over the obstacles.
There is also the matter of the old code base, the lack of a clean
separation between passes, and, most important, weak internal
documentation.
For example, in my view of internal documentation:
How to write a new backend: good.
Details of RTL IR: adequate.
Details of GIMPLE IR: poor.
Details of tree IR: poor.
How to write a new optimization pass: poor.
How to write a new frontend: nonexistent.
General overview of compiler source: nonexistent.
Overview of internal compiler datastructures: nonexistent.
I am as responsible for this state of affairs as anybody.
Ian