On Wed, 13 Jan 2010, Joern Rennecke wrote: > Quoting "Joseph S. Myers" <jos...@codesourcery.com>: > > If you want to have documentation extracted from source files, you need to > > engage with the SC and FSF at an early stage to get suitable license > > exception wording to permit the relevant text to be used in the manuals as > > well as the main (GPL) sources. > > I haven't gotten any reply to my proposal from the 5th of January > http://gcc.gnu.org/ml/gcc/2010-01/msg00082.html > > Is the GCC mailing list no longer the right place to reach the steering > committee?
It is the right place, but you should start a new thread with just the relevant issue and an appropriate subject line marked for the attention of the SC. You should expect it to take at least several months for the FSF to prepare an exception (worded as additional permissions under Section 7 of GPL version 3, like COPYING.RUNTIME, *not* as an old-style "As a special exception"), maybe years, if the SC persuades them that there should be such an exception. > > Of course, the ordering and (especially) > > section divisions in the internals manual are human-designed not arbitrary > > so you need to retain the ability to put the documentation of each hook in > > an appropriate position in an appropriate section of the manual. > > I have posted my current patch here: > http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00559.html > > > If you can make this work it should reduce the risk of people not > > documenting new hooks > > We actually have a number of instances where the target hook documentation is > out of sync with the sources. I have attached a file with my notes on this. 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. > > , but for it to work the FSF agreement is critical > > So who do I have to talk to for this? The SC. Not in the middle of a technical thread, but a thread on its own marked for the SC and indicating exactly what you want them to raise with the FSF. > tm.texi is half a megabyte, so it would be nice not to have it as a generated > file in the repository. Also, it'd be annoying to have to regenerate & check > it in for every target.def change even though the build works fine with > the generated file in the build directory. > Will it be acceptable to have update_web_docs build a generator program > (written in C) to rebuild tm.texi? It already builds a generator program in Ada for the Ada manual, so yes. -- Joseph S. Myers jos...@codesourcery.com
