|From:||Ian Lance Taylor <iant-AT-google.com>|
|To:||"Weddington, Eric" <Eric.Weddington-AT-atmel.com>|
|Subject:||Re: dragonegg in FSF gcc?|
|Date:||Mon, 12 Apr 2010 15:41:01 -0700|
|Cc:||Manuel LÃ³pez-IbÃ¡Ã±ez <lopezibanez-AT-gmail.com>, "Dave Korn" <dave.korn.cygwin-AT-googlemail.com>, "Jack Howarth" <howarth-AT-bromo.med.uc.edu>, "Steven Bosscher" <stevenb.gcc-AT-gmail.com>, "Duncan Sands" <baldrick-AT-free.fr>, <gcc-AT-gcc.gnu.org>|
"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
Copyright © 2010, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds