From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31279 invoked by alias); 13 Jan 2010 16:09:24 -0000 Received: (qmail 31263 invoked by uid 22791); 13 Jan 2010 16:09:22 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,MIME_QP_LONG_LINE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: sourceware.org Received: from c60.cesmail.net (HELO c60.cesmail.net) (216.154.195.49) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 13 Jan 2010 16:09:18 +0000 Received: from unknown (HELO epsilon2) ([192.168.1.60]) by c60.cesmail.net with ESMTP; 13 Jan 2010 11:09:17 -0500 Received: from 78.147.241.97 ([78.147.241.97]) by webmail.spamcop.net (Horde MIME library) with HTTP; Wed, 13 Jan 2010 11:09:17 -0500 Message-ID: <20100113110917.vqaoqpyyc0ck8gso-nzlynne@webmail.spamcop.net> Date: Wed, 13 Jan 2010 16:09:00 -0000 From: Joern Rennecke To: "Joseph S. Myers" Cc: 'GCC Mailing List' , Grigori Fursin , ctuning-discussions@googlegroups.com, 'Yuanjie Huang' , 'Liang Peng' , 'Zbigniew Chamski' , 'Yuri Kashnikoff' , 'Diego Novillo' Subject: Re: target hooks / plugins References: <4AE6E471.4020200@starynkevitch.net> <4AE70C5E.4050005@starynkevitch.net> <84fc9c000910270839v2d9efe0dw829c8647f361c96f@mail.gmail.com> <4AE7164D.9010200@starynkevitch.net> <84fc9c000910270855w736df367qe511d8db280aaeb4@mail.gmail.com> <2dc303d60910271056h17038110ib63c53cfa374f5c7@mail.gmail.com> <20091102074959.p8410ulv28sg0w44-nzlynne@webmail.spamcop.net> <20091105082557.75c2estyoog8ss0c-nzlynne@webmail.spamcop.net> <-2186575642631489790@unknownmsgid> <55692dc10911050634y54a5fea7jd2ba773086cda60b@mail.gmail.com> <00d801ca5e34$e5384160$afa8c420$@fursin@inria.fr> <20091223101256.z6a8ug32o8k84o4o-nzlynne@webmail.spamcop.net> <20091223193244.hqaet9zf488gw844-nzlynne@webmail.spamcop.net> <20100113032220.pzerwhbtog0w4gsk-nzlynne@webmail.spamcop.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) 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: 2010-01/txt/msg00282.txt.bz2 Quoting "Joseph S. Myers" : > Please note that your initial change to implement automatic doc extraction > should not result in any changes to the Texinfo content of the manual. > Such fixes should all go in either before or after the automatic doc > extraction change, but not at the same time; the doc extraction change > should result in identical text in the manual, but with the Texinfo files > produced in a different way. I recommend sending such fixes before the > automatic doc extraction change, since they do not depend on the FSF doing > anything. Duplicating all these changes separately by hand seems nigh impossible. I think the best approach is then to take the auto-generated tm.texi as the new tm.texi, and packages it up as a patch together with the struct member / hook name changes that I made for consistency. There is only one issue with using the current auto-generated tm.texi: Unless special formatting was in force (e.g. @smallexample), I've removed intra-paragraph newlines. This should work in principle just as will as with these newlines for producing output, but it looks somewhat daft in tm.texi when you consider it as a source file. Putting newlines in the input file would make it harder to read & edit, since the documentation comes as C strings - and the GNU multiline string extension has been deprecated some time ago. I could pipe the documentation through fold -s, but that would also fold extra-long lines outside the hook documentation, e.g.: @@ -28,7 +28,8 @@ @menu * Target Structure:: The @code{targetm} variable. * Driver:: Controlling how the driver runs the=20=20 compilation passes. -* Run-time Target:: Defining @samp{-m} options like=20=20 @option{-m68000} and @option{-m68020}. +* Run-time Target:: Defining @samp{-m} options like @option{-m68000} a= nd +@option{-m68020}. * Per-Function Data:: Defining data structures for per-function=20=20 information. * Storage Layout:: Defining sizes and alignments of data. * Type Layout:: Defining sizes and properties of basic user=20=20 data types. So I suppose I'll have to add some fold mechanism into the documentation output code.