Re: Newbie

[brent verner <brent at rcfile dot org>]

On 25 Oct 2000 at 00:28 (-0500), Bill Wendling wrote:
| Hi all,
| 
| I've been lurking a bit and was wondering what's the best way to become
| involved in gcc development? I.e., where does one start? Are there
| projects which people are doing which need help?

forewarning: I'm not really 'involved' in gcc development, in fact
  i'm pretty much floundering on the fringe of it all, so hopefully
  someone really involved will help clue us all in :)

(to the last question)
  I'm not sure the point-me-at-some-work-to-do is really applicable to
  this (and other large, unwieldy) project(s); meaning that, IMO, the 
  commitment necessary to learn all that is necessary to productively
  contribute to gcc is most often associated with one's desire to 
  scratch an itch -- don't get me wrong, the compiler _is_ fascinating,
  but unless you have a clear idea of what you intend to accomplish, 
  you can literally spend an eternity learning/relearning gcc's 
  codebase.

(back to the main question)
  this is an excellent question :)  perhaps too few people ask it.
  as I have no training in the art of code, nor vast experience,
  I'm struggling to develop my skills/understanding to a point
  where I might be able to contribute. my comments likely only
  apply to frontend development.

  basic:
    1) know the tools you're gonna use _well_:
      a) gdb -- batch mode rocks!
      b) C
      c) auto(conf|make|header)
      d) lex/yacc
    2) have _much_ time to devote.
    3) know how compilers work (???)
    4) read this list. download the mbox formatted archives.
    5) be a super-genius (note: i fail this requirement, so I hope
       it is not really a requirement)
    6) (more ???)

  pick an path:
    fix a bug:
      pick a bug. study the code. someone will likely fix it before
      you grok the code enough to solve the problem (correctly), but 
      you'll know more than you originally did, making the next

    documentation:
      teaching is one of the best ways to learn. after reading the
      existing documentation, submit a patch adding documentation
      where you _really_ wish it had been.

    add a feature:
      if you know of a feature (one of the) compiler(s) lacks,
      and you have deep enough experience with the language your
      feature deals with, this path may be for you, but I'd imagine
      your time'd be best spent fixing a few bugs in the area before
      making bulk additions to the code.

    (others: ???)

  learning the code (in order of importance):
    1) _know_ gdb. inside, out, any-which-way it bends -- and it
       does. gdb is your friend.
    2) read the gcc documentation, as well as comments in code.
    3) assuming you've picked a chunk of the code you can wrap
       your head around; break it, bend it, make it do something
       silly.
    4) ask specific questions when confused.
    5) participate in discussions related to your area of interest.
    6) find somebody to pay you to do all of the above (anybody
       looking for a would-be-coder-if-he-had-a-brain :)
    7) (more ???)


hth.
  brent (floundering less daily)

-- 
All opinions expressed are My own, unless otherwise attributed. In
presenting facts, I expressly reserve the right to be Wrong. Portions
of this message authored by Me are subject to the Free Thought License.