Sender: rich AT phekda DOT freeserve DOT co DOT uk Message-ID: <3E43C077.485354B9@phekda.freeserve.co.uk> Date: Fri, 07 Feb 2003 14:19:35 +0000 From: Richard Dawe X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.23 i586) X-Accept-Language: de,fr MIME-Version: 1.0 To: djgpp-workers AT delorie DOT com Subject: Re: Add @tindex for types in docs [PATCH] References: <3E3FDCB5 DOT D2875A7E AT phekda DOT freeserve DOT co DOT uk> <2561-Wed05Feb2003174006+0200-eliz AT is DOT elta DOT co DOT il> <3E428516 DOT 6E9BF039 AT phekda DOT freeserve DOT co DOT uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Hello. Esa A E Peuha wrote: > > On Thu, 6 Feb 2003, Richard Dawe wrote: > > > Another solution to problem (a) is to get mkdoc to do the hard work. mkdoc > > could generate a file containing all the -I options. > > Why not simply have mkdoc do the inclusion itself? After all, even now > mkdoc reads all the .txh files into memory first and only then dumps > them to libc2.tex; it would be quite easy to make it dump pieces of text > more than once. And I'd also like mkdoc to read libc.tex and actually > output one single Texinfo file which neither includes other files nor is > included by other files; then it would be easier to use mkdoc for > utils.info as well as libc.info. It just seems like overkill to have mkdoc do all this stuff, when texinfo already has @include. It sounds like you want mkdoc to become a much more feature-full pre-processor. If that's the case, why don't we split mkdoc into two: a program to find all .txh and some m4 macros to do the pre-processing? (Clearly this suggestion won't fly, because it would force another tool requirement on the build process.) Bye, Rich =] -- Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]