Re: Building the .info files in build directory.

[Ralf Corsepius]

On Fri, 2004-03-12 at 04:11, Simon Richter wrote:
> Simon,
> 
> > > [Info files being built in source dir]
> 
> > > When the source dir is readonly, noone can change the texinfo files. If
> > > noone can change the texinfo files, there is no need to rebuild the info
> > > files, so it doesn't matter that they're in a readonly directory.
> 
> > I don't think this is true in general, a texinfo file could @include a
> > file that is built during the build phase.
> 
> True, however that's a bad thing IMO, as it requires the user to have a
> working texinfo installation. 

IMO this is a non-argument, because this is a similar "bad thing" as
requiring a functional compiler or any other arbitrary tool.

> > (For example, I generate Texinfo code documenting the library based on
> > comments in the source files, and some source files may be generated,
> > as in foo.h.in -> foo.h to add version information to a header file.
> > Compare http://josefsson.org/gdoc/.)
> 
> I've not yet come across a point where it is necessary or a good idea to
> extract documentation from source files generated at the user's site.
IMO, these actually are two different issues:

1. Generating dos at the user's site instead of shipping them prebuilt:
This can significantly reduce the size of source tarballs. This is not
necessarily true for texi, but applies to other tools, e.g. doxygen
generated docs can easily reach several MBs. If texinfo should start to
provide html, rtf, ps, pdf or other output formats, as it had been
discussed recently, the same considerations would apply to it.

2. Generating docs from user-side generated files:
This case occurs when a package contains optional features and optional
sub-packages. A pretty common case, for example is to generate
cross-refs and indexes to sub-packages' documents in a "master"
document.

Ralf