This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Jul 21 13:37, Jon TURNEY wrote: > > As I wrote a while ago, I've been looking for a better way to generate the > Cygwin package containing manpages for newlib. > > Attached is a patch implementing a replacement for the makedoc tool, which > generates DocBook XML rather than .texinfo, which can then be processed into > manpages and other formats. > > I would appreciate any comments you have on the approach and the > implementation. > > > There are at least the following issues with this patch: > > * This only converts to DocBook the minimum necessary to generate manpages. > > Converting the full content of libc.texinfo, libm.texinfo, sys.tex, > reent.tex, iconv.tex, etc. is hard to do automatically, so would need to be > done by hand. > > Since maintaining the documentation in two formats seems unlikely to be a > good idea, this would mean fully converting to DocBook, removing all the > current texinfo source and .info generation and generating the .info from > DocBook instead. Do I understand you correctly? Do you suggest to convert the documentation in the C files to DocBook XML format? > * There's a lot of boilerplate in all the Makefiles to generate > documentation, and this adds more. I don't know why this isn't in > Makefile.shared Historical oversight, I guess. Feel free to move as much of the shared stuff into Makefile.shared. > * This fails to fully achieve the objective of generating good manpages. A > few functions (e.g. sccanf, ssprintf) use nested tables in a way which can't > be represented by troff markup (see [1]). So the markup of the > documentation for these functions would need to be improved, presumably by > writing it directly in DocBook. Ok, so that's probably what we should do. That allows to generate almost any other format one can think of, PDF, PS, info, man, ... The problem is probably just that "somebody has to do it". > * I haven't tested that documentation is correctly included/excluded > depending on the newlib configuration. > > * build avoidance needs doing correctly > > * The documentation license contains a clause specifically permitting > printing after processing with Tex. Presumably the copyright holder, Red > Hat, would need to approve a change permitting printing after processing > with other tools. The copyright holder is not Red Hat. Many files have different copyrights and copyright holders. But I don't think that's a problem. I assume that the general idea was to make sure that it's allowed to print the docs in the first place. Jeff, any input to this? Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat
Attachment:
pgpOwhUw5c9ry.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |