This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: target hooks / plugins
- From: Joern Rennecke <amylaar at spamcop dot net>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: 'GCC Mailing List' <gcc at gcc dot gnu dot org>, Grigori Fursin <grigori dot fursin at inria dot fr>, ctuning-discussions at googlegroups dot com, 'Yuanjie Huang' <huangyuanjie at ict dot ac dot cn>, 'Liang Peng' <pengliang at ict dot ac dot cn>, 'Zbigniew Chamski' <zbigniew dot chamski at gmail dot com>, 'Yuri Kashnikoff' <yuri dot kashnikoff at gmail dot com>, 'Diego Novillo' <dnovillo at google dot com>
- Date: Wed, 13 Jan 2010 11:09:17 -0500
- Subject: Re: target hooks / plugins
- References: <4AE6E471.4020200@starynkevitch.net> <mcr3a54lwb4.fsf@dhcp-172-17-9-151.mtv.corp.google.com> <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> <Pine.LNX.4.64.0912241209420.32398@digraph.polyomino.org.uk> <20100113032220.pzerwhbtog0w4gsk-nzlynne@webmail.spamcop.net> <Pine.LNX.4.64.1001131343010.2183@digraph.polyomino.org.uk>
Quoting "Joseph S. Myers" <joseph@codesourcery.com>:
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
compilation passes.
-* Run-time Target:: Defining @samp{-m} options like
@option{-m68000} and @option{-m68020}.
+* Run-time Target:: Defining @samp{-m} options like @option{-m68000} and
+@option{-m68020}.
* Per-Function Data:: Defining data structures for per-function
information.
* Storage Layout:: Defining sizes and alignments of data.
* Type Layout:: Defining sizes and properties of basic user
data types.
So I suppose I'll have to add some fold mechanism into the documentation
output code.