gnuplot-beta

Why docs/term.h ???

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

Hi, folks,

to my considerable surprise, I've just discovered that, as of December
2002, the build of online help no longer masks out terminal drivers. Our
Debian package maintainer just forwarded this to us, as a bug report.

This used to be done by having docs/termdoc.c #include docs/allterm.h for
printable doc files, or src/term.h for online versions that should match
what is actually present in term.h.

But Lars introduced a change (revision 1.44 of docs/Makefile.in) that
relies on a separate file, docs/term.h, built by concatenating and
preprocessing the config.h file and a selection of terminal driver
sources listed in docs/Makefile.in, $(CORETERM):

term.h: $(CORETERM)
        @echo "Building term.h"
        @cat ../config.h $(CORETERM) > term.c
        $(CPP) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(CPPFLAGS)  \
            -DTERM_DRIVER_H -DTERM_HELP term.c | \
          sed '/^ *$$/d;/^#/d' >$@
        @rm -f term.c

The problem with this construction is that the logical connection between
config.h and the decision which terminal drivers to include exists *only*
inside src/term.h, so this method completely fails to screen out the
unwanted drivers.

So: why can't the doc2*.o files just refer to ../src/term.h?  What is
docs/term.h needed for?  I guess this question goes mainly to Lars, but
any insight from others would be valuable.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Why docs/term.h ???

[Lars H. <lhe...@us...>]

> But Lars introduced a change (revision 1.44 of docs/Makefile.in) that
> relies on a separate file, docs/term.h, built by concatenating and
> preprocessing the config.h file and a selection of terminal driver
> sources listed in docs/Makefile.in, $(CORETERM):
> 
> term.h: $(CORETERM)
>         @echo "Building term.h"
>         @cat ../config.h $(CORETERM) > term.c
>         $(CPP) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(CPPFLAGS)  \
>             -DTERM_DRIVER_H -DTERM_HELP term.c | \
>           sed '/^ *$$/d;/^#/d' >$@
>         @rm -f term.c
> 
> The problem with this construction is that the logical connection between
> config.h and the decision which terminal drivers to include exists *only*
> inside src/term.h, so this method completely fails to screen out the
> unwanted drivers.
> 
> So: why can't the doc2*.o files just refer to ../src/term.h?  What is
> docs/term.h needed for?  I guess this question goes mainly to Lars, but
> any insight from others would be valuable.
 
 Had to go back to the list archive ...

 There was a discussion here, Subject: "LaTeX docs, and docs cleanup",
 involving Petr, Ethan, and myself wrt alphabetical order of help
 entries. That was solved for allterm.h, where it matters.

 I think the idea behind intorducing docs/term.h was to simplify the
 makefile somewhat, but the problem is indeed that config.h alone does
 not mask out unwanted drivers, which was the assumption.

Re: Why docs/term.h ???

[Petr M. <mi...@ph...>]

> But Lars introduced a change (revision 1.44 of docs/Makefile.in) that
> relies on a separate file, docs/term.h, built by concatenating and
> preprocessing the config.h file and a selection of terminal driver
> sources listed in docs/Makefile.in, $(CORETERM):
>
> term.h: $(CORETERM)
>         @echo "Building term.h"
>         @cat ../config.h $(CORETERM) > term.c
>         $(CPP) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(CPPFLAGS)  \
>             -DTERM_DRIVER_H -DTERM_HELP term.c | \
>           sed '/^ *$$/d;/^#/d' >$@
>         @rm -f term.c
>
> The problem with this construction is that the logical connection between
> config.h and the decision which terminal drivers to include exists *only*
> inside src/term.h, so this method completely fails to screen out the
> unwanted drivers.
>
> So: why can't the doc2*.o files just refer to ../src/term.h?  What is
> docs/term.h needed for?  I guess this question goes mainly to Lars, but
> any insight from others would be valuable.

In summary: it is obviously only gnuplot.gih which likes to be created with
only those terminals compiled into the gnuplot executable, right?

Then, the particular piece of Makefile, should use the original method of
creating its own xxxterm.h, and delete it after creation. All other output
formats of gnuplot documentation will lists all terminals.

Should it be like that?

---
PM

Re: Why docs/term.h ???

[Ethan M. <merritt@u.washington.edu>]

On Tuesday 01 June 2004 09:22 am, Petr Mikulik wrote:

> > So: why can't the doc2*.o files just refer to ../src/term.h?  What is
> > docs/term.h needed for?  I guess this question goes mainly to Lars,
> > but any insight from others would be valuable.
>
> In summary: it is obviously only gnuplot.gih which likes to be created
> with only those terminals compiled into the gnuplot executable, right?

There is still a vestigial target in the docs Makefile called "allgih",
which was originally there to provide the option of listing all terminal
in the on-line help.  Intentionally or not, this has now become the
default.

I have no objection to restoring the original behavior of "make gih".
On the other hand I see little harm in including all the terminals in the 
on-line help, so long as "set term" provides a correct list of which
terminals are actually available.



-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195