On Wed, Jan 23, 2013 at 8:38 PM, Diego Novillo <dnovi...@google.com> wrote: > [ We have drifted way off the original subject. ] > > > On Wed, Jan 23, 2013 at 2:16 PM, Uday Khedker <u...@cse.iitb.ac.in> wrote: > >> Yes, absolutely. And GCC community should consider it important to bring in >> newcomers particularly young students and experimenters from the academia. >> >> Why is it that most student projects these days are on LLVM and not on GCC? >> Had these students been doing projects on GCC, some of them may turn >> contributors in future. > > Yes. This is an issue for the long term viability of GCC as a > project. In fact, I sometimes think that we may be past the tipping > point. > > Note that the very set of developers that can fix these problems are, > traditionally, the least likely to do much about it. These developers > are already comfortable with the codebase, they know how to do the > things they are hired to do and employers are largely on the same > boat. Additionally, established developers will generally resist > change, because these changes lead to short-term instability and bugs > (the releng/maintainer mindset). > > Evolving this codebase is largely a thankless and difficult job. It's > technically interesting to me, but I know I can only do so much. We > have other demands on our time and often this conflicts with the > nature of these changes. Some developers have done some work here and > there to improve the codebase, but GCC's accumulated technical debt is > large. > > If this trend continues, the pool of experienced GCC developers will > eventually start to dwindle. Without developer renewal, GCC will > naturally die out. This cycle has happened many times before and it > will continue to happen. Yet, it would be interesting to have two or > more strong competing open source compilers. The cross-pollination > that open source competition encourages is beneficial to all (users > and developers).
Note that we can't drive GCC into the garage and refactor it for two years. Any refactoring done has to be while being live on the road! Which essentially limits on what kind of refactoring is possible - which also may limit the ultimate outcome of the sum of all refactorings. Always have this in mind before you turn GCC into an even greater mess than it is! The most important "refactoring" to a newcomer would IMHO be to further disentangle the already present components - both in the source tree structure as well as in separating (and moving together) of interfaces. Next easy part of that job is to create gcc/driver/ (gcc.c, collect2.c, etc.) and gcc/build/ (gen*.c). Then maybe add a getting-started section to the internals manual, eventually just pointing out external resources. Likewise refer to getting started material from contriubte.html which is where contributors will end up I suppose. Richard. > > Diego.
