Simon Richter wrote: > > 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. > > > (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. > > For stuff that depends on the local software configuration [[...]]
Fundamentally, I think the argument boils down to whether or not .texi/.info files should get built at a client (customer) site. The answer is that it must be possible. Just because some folks think one ought not do such a thing doesn't make it reasonable to make doing it impossible. What does make sense is having a special phoney target which, when specified, says, "I have all the tools for reconstructing docs from scratch. Please re-derive and rebuild them." and then construct the dependencies in such a way that they are independent of the default/"all" target.
