From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22865 invoked by alias); 26 Oct 2007 19:11:49 -0000 Received: (qmail 22850 invoked by uid 22791); 26 Oct 2007 19:11:47 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 26 Oct 2007 19:11:44 +0000 Received: from zps38.corp.google.com (zps38.corp.google.com [172.25.146.38]) by smtp-out.google.com with ESMTP id l9QJBcM0004356 for ; Fri, 26 Oct 2007 12:11:38 -0700 Received: from ug-out-1314.google.com (ugem2.prod.google.com [10.66.164.2]) by zps38.corp.google.com with ESMTP id l9QJBWjD001867 for ; Fri, 26 Oct 2007 12:11:38 -0700 Received: by ug-out-1314.google.com with SMTP id m2so783501uge for ; Fri, 26 Oct 2007 12:11:37 -0700 (PDT) Received: by 10.78.186.9 with SMTP id j9mr2608863huf.1193425897516; Fri, 26 Oct 2007 12:11:37 -0700 (PDT) Received: by 10.78.25.2 with HTTP; Fri, 26 Oct 2007 12:11:37 -0700 (PDT) Message-ID: Date: Fri, 26 Oct 2007 19:44:00 -0000 From: "Diego Novillo" To: "Basile STARYNKEVITCH" Subject: Re: RFC: Creating a live, all-encompassing architectural document for GCC Cc: gcc@gcc.gnu.org In-Reply-To: <4722253D.3000102@starynkevitch.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4722253D.3000102@starynkevitch.net> X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2007-10/txt/msg00531.txt.bz2 On 10/26/07, Basile STARYNKEVITCH wrote: > Maybe a possible approach would be to use literate programming > techniques; By previous experience (still limited), I would believe that > it would be more worthwhile on the interface files (ie the *.h files, > some *.opt, etc...) than on the implementation files (*.c) Pragmatically, we need to do this without forcing such structural changes to the implementation. Moving GCC to another language is another problem that I'd like to keep separate from this. > All this is more a social issue than anything else. We developers don't > like documenting our work (and this is sadly true for me too!) Agreed. The documentation mechanism ultimately needs to be easy to improve. It will always be incomplete and imperfect. I simply want to make it less so. > (Diego, I am busy preparing the basilys branch, see my GCC summit paper). Good to hear. Thanks.