Re: gnuplot.texi missing postscript terminal docs

[Hans-Bernhard B. <br...@ph...>]

Juergen Wieferink wrote:

[Please try to stick with one email address --- so I don't have to
manually approve your postings from the "wrong" one, only to find that
you've re-posted them under the correct address in the meantime...]

> The attached patch is a proof of concept for an extension of 
> doc2texi.el.  AFAICS it works.  It calls the preprocessor from within
>  doc2texi.el.  This could be done somewhat more portable than just 
> calling "cpp -DTERM_HELP", though.

It quite probably must be, too.  For starters, the preprocessor isn't
called 'cpp' everywhere, and you'll almost certainly have to provide
some other macros to make *all* terminal help work correctly.

We used to process all terminal drivers through the preprocessor to
create files docs/term.h and docs/allterm.h, until I disabled that
mechanism --- it was causing problems elsewhere.

Having doc2texi.el invoke CPP doesn't exactly seem like the most elegant
solution possible.  But if it works, it's worth a shot.

> How portable should this step be?

As portable as it can possibly be.

 > Will gnuplot.info be prebuilt in releases?

No.  But gnuplot.texi, the direct output of doc2texi.el, will be.

But releases aren't the main point of concern here.  CVS checkins from 
non-GNUish platforms are.  gnuplot.texi itself is contained in CVS 
(although arguably, it shouldn't be), and rebuilt each time gnuplot.doc 
changes (it should be rebuilt if any terminal changes, too, but 
docs/Makefile.in fails to say so).  So a "cvs checkin" without a list of 
files to be checked in (so all new files will be checked in, including 
gnuplot.texi), done from a platform that doc2texi.el fails to run 
properly on could generate some nuisance.  As such, it's rather 
important that doc2texi.el behaves portably.