gnuplot-beta — Developers and beta testers of new gnuplot code

Re: PDFlib Lite vs. the gnuplot Copyright license

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:

>On Tue, 13 Apr 2004, Daniel J Sebald wrote:
>
>  
>
>>No "set term pdf" then?  Bummer.  At the OSI site are a couple dozen 
>>licenses that could be chosen and applied without further review; at 
>>least, I think that is what they are saying. 
>>    
>>
>
>Except that's not for us (the currently active group of developers) to do
>in the first place.  Changes to the license can *only* be done by the
>Copyright holders.  That's mainly Tom Williams, plus a handful of others.  
>They'ld all have to be contacted, and agree on a simultaneous change.  
>That would probably take even longer than getting the current license
>approved.
>

Ah.

>>What is it about Gnuplot in philosophy that varies from licenses 
>>currently out there?  Some core principle?  
>>    
>>
>
>gnuplot's license is quite ancient.  It's been around longer than just
>about all the others you'll find in OSI's list except the big 4 (BSD, MIT,
>GPL and LGPL).  Originally it was rather restrictive, like the Minix
>license in that you weren't allowed to distributed binaries from modified
>source, nor even modified sources themselves.  I.e. you were supposed to
>distribute all mods as patches to the "official" source code.
>
>We convinced Tom Williams as of 3.7 to drop the "no distribution of
>binaries from modified sources" clause, but the "no distribution of
>modified sources" one still stands.
>
>Most of us would probably welcome a move to GPL, but that apparently won't
>happen.
>
>  
>
>>Does it pay to look through the list of approved licenses to see if
>>there is something that closely matches Gnuplot's "Copyright" file?
>>    
>>
>
>It may, but I for one won't have time to do it.
>

Well, it looks like this would have to be done anyway as part of the 
approval process.  (Must tell the approval discussion list which of the 
already approved licenses are closest to yours and what about yours is 
different.)

Dan

Re: PDFlib Lite vs. the gnuplot Copyright license

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

On Tue, 13 Apr 2004, Daniel J Sebald wrote:

> No "set term pdf" then?  Bummer.  At the OSI site are a couple dozen 
> licenses that could be chosen and applied without further review; at 
> least, I think that is what they are saying. 

Except that's not for us (the currently active group of developers) to do
in the first place.  Changes to the license can *only* be done by the
Copyright holders.  That's mainly Tom Williams, plus a handful of others.  
They'ld all have to be contacted, and agree on a simultaneous change.  
That would probably take even longer than getting the current license
approved.

> What is it about Gnuplot in philosophy that varies from licenses 
> currently out there?  Some core principle?  

gnuplot's license is quite ancient.  It's been around longer than just
about all the others you'll find in OSI's list except the big 4 (BSD, MIT,
GPL and LGPL).  Originally it was rather restrictive, like the Minix
license in that you weren't allowed to distributed binaries from modified
source, nor even modified sources themselves.  I.e. you were supposed to
distribute all mods as patches to the "official" source code.

We convinced Tom Williams as of 3.7 to drop the "no distribution of
binaries from modified sources" clause, but the "no distribution of
modified sources" one still stands.

Most of us would probably welcome a move to GPL, but that apparently won't
happen.

> Does it pay to look through the list of approved licenses to see if
> there is something that closely matches Gnuplot's "Copyright" file?

It may, but I for one won't have time to do it.

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

Re: PDFlib Lite vs. the gnuplot Copyright license

[Daniel J S. <dan...@ie...>]

No "set term pdf" then?  Bummer.  At the OSI site are a couple dozen 
licenses that could be chosen and applied without further review; at 
least, I think that is what they are saying.  When you speak of an 
actual lawyer reviewing the license, you mean because Gnuplot's is not 
any of the OSI confirmed it would have to be reviewed, right?  And for 
Gnuplot, the "license" is the file "Copyright"?  But that file is 
somewhat skimpy in legalese compared to the example licenses at OSI.

Oh, but wait.  Skimpiness apparently doesn't preclude approval.  There 
is a "zlib/libpng" license that is even less than what appears in the 
file "Copyright".  But still, even though it would take a J.D. little 
time to analyze a short license, the OSI process probably takes a week 
or two.

What is it about Gnuplot in philosophy that varies from licenses 
currently out there?  Some core principle?  Does it pay to look through 
the list of approved licenses to see if there is something that closely 
matches Gnuplot's "Copyright" file?

Dan


Hans-Bernhard Broeker wrote:

>Gents, 
>
>as part of my ongoing discussion by mail with the PDFLib people, I've just
>found an issue that would quite certainly mean we can't distribute gnuplot
>binaries with the PDF driver built in.  PDFLib Lite grants an exemption to
>open-source projects, but *only* if they have their license formally
>approved by the OSI (Open Source Initiative).  But the gnuplot license is
>not approved by OSI, and I see no way whatsoever we can get it approved in
>time for the imminent release.  For starters, they want us to supply an
>analysis of our license done by an actual lawyer, for which I think we
>have neither the time nor the money.
>
>This means that for the time being, the open-source usage exemption of
>PDFLib Lite doesn't apply to gnuplot.  The other exemptions are for
>private or research usage, which we can't rely on for our public binaries.
>
>It's also somewhat unclear what exactly PDFLib Lite wants us to include in
>a binary built using their library.  Their licence is apparently written
>with the idea of a shared library used by somebody else's program in mind.
>It doesn't make any sense whatsoever in the context of a statically linked
>gnuplot release having it compiled into its monolithic executable.
>
>So, in a nutshell: no pdf.trm in any of the release binary packages!
>
>  
>

-- 

Dan Sebald
email: daniel DOT sebald AT ieee DOT org
URL: http://acer-access DOT com/~dsebald AT acer-access DOT com/

PDFlib Lite vs. the gnuplot Copyright license

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

Gents, 

as part of my ongoing discussion by mail with the PDFLib people, I've just
found an issue that would quite certainly mean we can't distribute gnuplot
binaries with the PDF driver built in.  PDFLib Lite grants an exemption to
open-source projects, but *only* if they have their license formally
approved by the OSI (Open Source Initiative).  But the gnuplot license is
not approved by OSI, and I see no way whatsoever we can get it approved in
time for the imminent release.  For starters, they want us to supply an
analysis of our license done by an actual lawyer, for which I think we
have neither the time nor the money.

This means that for the time being, the open-source usage exemption of
PDFLib Lite doesn't apply to gnuplot.  The other exemptions are for
private or research usage, which we can't rely on for our public binaries.

It's also somewhat unclear what exactly PDFLib Lite wants us to include in
a binary built using their library.  Their licence is apparently written
with the idea of a shared library used by somebody else's program in mind.
It doesn't make any sense whatsoever in the context of a statically linked
gnuplot release having it compiled into its monolithic executable.

So, in a nutshell: no pdf.trm in any of the release binary packages!

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

Re: misc for readmes

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

On Tue, 13 Apr 2004, Petr Mikulik wrote:

> > > BUGS:
> > >
> > >  *) compiling help file with Visual C++ 4.0/Windows NT
> > >     The help compiler coming with this version of MSVC++ appers unable
> > >     to compile gnuplot.rtf.  As a workaround download the freely
> > >     available "Help Workshop" from Microsoft and use that instead.
> > >
> > >
> > > => should not this be written to the makefile of MSVC++ ?
> >
> > No.  You need this help compiler for *all* Windows builds.  If at all, it
> > would have to be added to all of them (makefile.{nt,cyg,mgw,win}).
> >
> > > Or to the preface of "MS-Windows" section in INSTALL
> >
> > That'd be another good place, indeed.
> 
> I think it is the right place where it should be -- as it is already in
> makefile.mgw, .cyg:

I've put it into INSTALL.

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

Re: misc for readmes

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

On Tue, 13 Apr 2004, Petr Mikulik wrote:

> Ok then but ordinary people have no idea what that front-end is for, and
> just got confused immediately in README.1st. Could you please add 1
> sentence or a better title like "gnuplot-mode for emacs (??)  for
> (arbitrary??) OS".

Ah heck, all right then, I'm moving this into a separate file inside the
"lisp" directory.  It'll be called "README.1st" because there already
a README in there which is not written by us.

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

Re: misc for readmes

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

> > BUGS:
> >
> >  *) compiling help file with Visual C++ 4.0/Windows NT
> >     The help compiler coming with this version of MSVC++ appers unable
> >     to compile gnuplot.rtf.  As a workaround download the freely
> >     available "Help Workshop" from Microsoft and use that instead.
> >
> >
> > => should not this be written to the makefile of MSVC++ ?
>
> No.  You need this help compiler for *all* Windows builds.  If at all, it
> would have to be added to all of them (makefile.{nt,cyg,mgw,win}).
>
> > Or to the preface of "MS-Windows" section in INSTALL
>
> That'd be another good place, indeed.

I think it is the right place where it should be -- as it is already in
makefile.mgw, .cyg:

# To compile the .hlp file you need hcw either out of Microsoft SDK or MS Help
# Workshop. The latter can be obtained at www.helpmaster.com/help/devaids.htm.
# Put the path to hcw here unless it is already in PATH:
#HCWPATH = /Program\ Files/Help\ Workshop/
#HCWPATH = h:/mssdk/bin/
HCW = $(HCWPATH)hcw
# Switches are for HCW 4.03:
HCWFLAG =


Because, it's a makefile-related information, and not a BUG.
Please remove this from BUGS and copy the text from makefile.mgw to
makefile.nt.


---
PM

Re: misc for readmes

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

> > My old complaint:
> > I always find the "Note 3" completely useless and vote for removing it.
>
> That would be very unfriendly to the author of gnuplot-mode.  We can't
> just swallow a copy of his package into ours without explaining why that
> copy is incomplete.
>
> > (I don't consider myself to be an ordinary user of gnuplot but never met
> > gnuplot-mode; and I wonder how gnuplot 4.0 is affected by some files
> > not being present from this mode...)
>
> Frankly, whether or not anyone of *us* is using that package is completely
> irrelevant.  gnuplot-mode is a user-interface to gnuplot that people are

Ok then but ordinary people have no idea what that front-end is for, and
just got confused immediately in README.1st. Could you please add 1 sentence
or a better title like "gnuplot-mode for emacs (??)  for (arbitrary??) OS".

Then, about those file which are missing (compared to what? link to the web
site of this mode as the "Front-ends" section on gnuplot's web page?), could
rather be written in its own directory then in README.1st which will be read
by more people then lisp/README.


---
PM

Re: misc for readmes

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

On Tue, 13 Apr 2004, Petr Mikulik wrote:


> 
> gnuplot.sf.net  as a download side shoule be mentioned too

Of course. It is in my working copy.  Except that gnuplot.sf.net itself
won't be the download site.  I'll point at the file release system
below sf.net/projects/gnuplot instead.

>   Send comments and requests for help to <inf...@da...>
>   Send bugs, suggestions and mods to <inf...@da...>
> 
> Shoudn't this be changed?

Again: already done in my working copy.

> BUGS:
> 
>  *) compiling help file with Visual C++ 4.0/Windows NT
>     The help compiler coming with this version of MSVC++ appers unable
>     to compile gnuplot.rtf.  As a workaround download the freely
>     available "Help Workshop" from Microsoft and use that instead.
> 
> 
> => should not this be written to the makefile of MSVC++ ?

No.  You need this help compiler for *all* Windows builds.  If at all, it
would have to be added to all of them (makefile.{nt,cyg,mgw,win}).

> Or to the preface of "MS-Windows" section in INSTALL

That'd be another good place, indeed.

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

Re: misc for readmes

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

On Tue, 13 Apr 2004, Petr Mikulik wrote:

> Here are some my observations (I've just read few INSTALL and README*,
> but no time to edit it today):
> 
> ***
> README.1ST
> 
> Text:
> generate and convert the images at the same time, as in this example:
>         set terminal png medium font LucidaSansDemiBold
>         set output '| convert png:- image.gif'
> 
> 
> I think it should be like
>     set term png font arial
> or
>     set term png medium
> but not both together

Right.  Will change that.

>     set term png font arial
>     set term png medium
> => it does not revert to medium; someone can have a look?

Ouch.  But it should be trivial to fix.  I'll have 'set term medium'
and friends turn off the TTF font option.

> My old complaint:
> I always find the "Note 3" completely useless and vote for removing it.

That would be very unfriendly to the author of gnuplot-mode.  We can't
just swallow a copy of his package into ours without explaining why that
copy is incomplete.

> (I don't consider myself to be an ordinary user of gnuplot but never met
> gnuplot-mode; and I wonder how gnuplot 4.0 is affected by some files
> not being present from this mode...)

Frankly, whether or not anyone of *us* is using that package is completely
irrelevant.  gnuplot-mode is a user-interface to gnuplot that people are
using (there's been the occasional question about it, including the one
which triggered this weekends' rediscovery of the Windows' !-command 
problem), and they have the right to know how the stuff in the 'lisp'
directory relates to the separate package they may have installed.

> There is a "gnuplot reference card" in docs/ -- but untouched since 1998.
> Could somebody edit it a bit (at least like set no => unset)?

Will do.

> Also, in lisp/gpelcard.tex, looks like yet another gp card -- but this is
> a bit wrong and outdated like here:
> 
> \item[Using pm3d] \hfill \\
>   All features of the pm3d patch to \textsc{gnuplot} should be
>   available when using gnuplot-mode.  One particularly useful feature
>   of pm3d is the ability to push a cursor position into the
>   clipboard.  This is done by double-clicking \texttt{mouse-1} in the
>   plot window, then doing \texttt{M-x yank-clipboard-selection}
>   (usually bound to \texttt{mouse-2}) in the gnuplot script buffer.
> 
> ... author obviously means Using mouse, and it's no more a patch.
> 
> How is this ref card related to docs/ one?

It's an indepentend work.  Meant to explain gnuplot-mode, not gnuplot
itself.  

> To be merged, deleted, ...?

To be kept (optionally updated slightly).


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

Re: ! shell-escapes on Windows.

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

On Tue, 13 Apr 2004, Petr Mikulik wrote:

> Oh really, it was not waiting to the end of execution ... does it wait now?

Apparently yes.  And even if it doesn't, that's still the best we can
do right now without cancelling the release.

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

Re: misc for readmes

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

remained in my clipboard:

****

README:

gnuplot.sf.net  as a download side shoule be mentioned too

***

gnuplot, when starts, prints:

  Send comments and requests for help to <inf...@da...>
  Send bugs, suggestions and mods to <inf...@da...>

Shoudn't this be changed?


***

BUGS:


 *) compiling help file with Visual C++ 4.0/Windows NT
    The help compiler coming with this version of MSVC++ appers unable
    to compile gnuplot.rtf.  As a workaround download the freely
    available "Help Workshop" from Microsoft and use that instead.


=> should not this be written to the makefile of MSVC++ ?
   (is it makefile.nt?)  I guess nobody will look to BUGS for this piece of
info.

Or to the preface of "MS-Windows" section in INSTALL


---
PM

Re: ! shell-escapes on Windows.

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

> > Proposed solution #1: get rid of winsystem() altogether.  Just call
> > system() like on all other platforms, and trust the compiler authors to
> > know what they're doing. Drawback: there's no time to go through a test
> > of'em all to make sure that assumption is reliable.
>
> Seizing an opportunity to have it tested on the second most important
> platform (besides Cygwin/MinGW32, that is), i.e. MSVC++,  I concluded
> that this is good enough to go, so I checked it in.
>
> (I actually left the code in, just disabled the actual call of
> winsystem() by an additional conditional, so we can tell users how
> to re-enable it easily if they have to...)

Oh really, it was not waiting to the end of execution ... does it wait now?

---
PM

misc for readmes

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

Here are some my observations (I've just read few INSTALL and README*,
but no time to edit it today):

***
README.1ST

Text:
generate and convert the images at the same time, as in this example:
        set terminal png medium font LucidaSansDemiBold
        set output '| convert png:- image.gif'


I think it should be like
    set term png font arial
or
    set term png medium
but not both together


WOW, there is a BUG in png:

    set term png font arial
    set term png medium
=> it does not revert to medium; someone can have a look?


---

My old complaint:
I always find the "Note 3" completely useless and vote for removing it.
(I don't consider myself to be an ordinary user of gnuplot but never met
gnuplot-mode; and I wonder how gnuplot 4.0 is affected by some files
not being present from this mode...)

***

GNUPLOT REFERENCE CARD(S)

There is a "gnuplot reference card" in docs/ -- but untouched since 1998.
Could somebody edit it a bit (at least like set no => unset)?
It could be put into web page if someone contributes.


Also, in lisp/gpelcard.tex, looks like yet another gp card -- but this is
a bit wrong and outdated like here:

\item[Using pm3d] \hfill \\
  All features of the pm3d patch to \textsc{gnuplot} should be
  available when using gnuplot-mode.  One particularly useful feature
  of pm3d is the ability to push a cursor position into the
  clipboard.  This is done by double-clicking \texttt{mouse-1} in the
  plot window, then doing \texttt{M-x yank-clipboard-selection}
  (usually bound to \texttt{mouse-2}) in the gnuplot script buffer.

... author obviously means Using mouse, and it's no more a patch.

How is this ref card related to docs/ one?
To be merged, deleted, ...?


---
PM

Re: ! shell-escapes on Windows.

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

On Mon, 12 Apr 2004, Hans-Bernhard Broeker wrote:

[...]

> Proposed solution #1: get rid of winsystem() altogether.  Just call
> system() like on all other platforms, and trust the compiler authors to
> know what they're doing. Drawback: there's no time to go through a test
> of'em all to make sure that assumption is reliable.

Seizing an opportunity to have it tested on the second most important
platform (besides Cygwin/MinGW32, that is), i.e. MSVC++,  I concluded
that this is good enough to go, so I checked it in.

(I actually left the code in, just disabled the actual call of 
winsystem() by an additional conditional, so we can tell users how
to re-enable it easily if they have to...)

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

! shell-escapes on Windows.

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

Gents,

an old issue just resurfaced after laying dormant for most of 2 years.
It's the behaviour of the '!' shell-escape on Windows platforms, and was
brought to our attention by Don Taber in 2002 without every reaching a 
conclusion.

Here's the beef: for a reason that's not explained particularly well,
wgnuplot rolls it's own version of the system() function to implement the
'!' command.  The home-grown version relies on a deprecated Windows API
entry WinExec(). That probably even made sense back in the days of 16-bit
Windows-3.x. but it's currently experiencing at least two serious
drawbacks.  Does anybody here still remember when, or why that code was
put in there in the first place?  It must have been there since at least
3.6.  For all I know, it could even be from the initial port to Windows.

The code in question is command.c:winsystem(), which essentially does
this:

	if (WinExec(cmd) fails)
	  WinExec("%COMSPEC% /c " + cmd);

The problems are:

1) WinExec() doesn't really wait for the called programm to finish the way
system() is supposed to.  This wreaks havoc to gnuplot scripts like

	! tool input -o output.dat
	plot 'output.dat'

2) WinExec doesn't support redirection or internal commands of the command
line processor.

The second WinExec() call is supposed to address issue 2) by handing the
job over to the shell, but fails to do so, silently, if the command is an
external .exe that just silently ignores the redirection options (--> the
first WinExec() succeeds).  It can be worked around by "hiding" this fact
from WinExec(), e.g. by prepending a space:

	!command > output.dat

will fail, but

	! command > output.dat

seems to work.  That's stupid, to put it mildly. And it still fails to
wait for the termination of the external command.

Proposed solution #1: get rid of winsystem() altogether.  Just call
system() like on all other platforms, and trust the compiler authors to
know what they're doing. Drawback: there's no time to go through a test
of'em all to make sure that assumption is reliable.

Proposed solution #2: only get rid of the if(), so the job always ends up
being done by the shell.  Drawback: wouldn't solve the wait-for-subcommand
issue at all.

Proposed solution #3: Like #2, but also change from WinExec to the
Win32-only function CreateProcess() with appropriate waiting.

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

Re: "make" touches /usr/share/emacs/site-lisp/

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

On Sat, 10 Apr 2004, James R. Van Zandt wrote:

[...]
> Both were generated by the same version of autoconf:
>   $ grep "generated.*autoconf" config.status /tmp/working/lisp/config.status
>   config.status:    echo "./config.status generated by autoconf version 2.13"
>   /tmp/working/lisp/config.status:    echo "./config.status generated by autoconf version 2.13"

This is wrong.  gnuplot doesn't work with autoconf-2.13 any longer.  You
must have version 2.52 or higher, as mentioned in the AC_PREREQ() of the
master configure.in.  Issued at hand are:

1) no, I don't think you're supposed to run ./configure in the lisp
directory manually.  Leave that to the master ./configure script and
tools.

2) it's not exactly a surprise that autoconf files generated by 2.13 with
automake-1.4/autoconf-2.52 generated ones don't mix well.

As a fix, I'll bump AC_PREREQ() in lisp/configure up to 2.52.

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

"make" touches /usr/share/emacs/site-lisp/

[James R. V. Z. <jr...@co...>]

somebody wrote:
> The only problem/annoyance I have is that the 'make' process tries
> to update files in the system directory /usr/share/emacs/site-lisp/,
> which means that I get error messages if I'm not building as root.
> Seems to be harmless, though.

I'm trying to reconstruct a different problem, and tripped over this.
My builds failed like this:

  make[2]: Entering directory `/home/local/src/gnuplot/cvs/gnuplot/lisp'
  /bin/sh ./mkinstalldirs /usr/local/share/emacs/site-lisp
   /usr/bin/install -c -m 644 gnuplot-gui.el /usr/local/share/emacs/site-lisp/gnuplot-gui.el
  /usr/bin/install: cannot remove `/usr/local/share/emacs/site-lisp/gnuplot-gui.el': Permission denied
  ...
  
I'm appending lisp/Makefile (sorry about the length).  Apparently the
offending commands come from the "install-els" target via this chain:
   
  all -> all-redirect -> all-am -> $(LISP) -> $(INSTALL_LISP)
      -> install-lisp -> install-els

the suspicious line being:

  all-am: Makefile $(LISP)

which comes from an identical line in lisp/Makefile.in.

I can reproduce this by running this in the lisp/ directory:

  make clean && ./prepare ; automake --add-missing --copy &&
  autoconf && ./configure && make

(There's no "prepare" script there, so that part fails.)
However, running the same commands in the top directory fixes things,
and the build succeeds.

Here are the file differences between the working and failing versions
of the lisp/ directory:
  
  $ diff --brief -r . /tmp/working/lisp
  Files ./Makefile and /tmp/working/lisp/Makefile differ
  Files ./Makefile.in and /tmp/working/lisp/Makefile.in differ
  Files ./config.status and /tmp/working/lisp/config.status differ
  Only in /tmp/working/lisp: gnuplot-gui.elc
  Only in /tmp/working/lisp: gnuplot.elc

Here are the differences in config.status:

  $ diff -u /tmp/working/lisp/config.status config.status
  --- /tmp/working/lisp/config.status	2004-04-10 10:55:38.000000000 -0400
  +++ config.status	2004-04-10 10:55:49.000000000 -0400
  @@ -4,7 +4,7 @@
   # This directory was configured as follows,
   # on host vanzandt:
   #
  -# ./configure  --prefix=/usr/local --cache-file=/dev/null --srcdir=.
  +# ./configure 
   #
   # Compiler output produced by configure, useful for debugging
   # configure, is in ./config.log if it exists.
  @@ -14,8 +14,8 @@
   do
     case "$ac_option" in
     -recheck | --recheck | --rechec | --reche | --rech | --rec | --re | --r)
  -    echo "running ${CONFIG_SHELL-/bin/sh} ./configure  --prefix=/usr/local --cache-file=/dev/null --srcdir=. --no-create --no-recursion"
  -    exec ${CONFIG_SHELL-/bin/sh} ./configure  --prefix=/usr/local --cache-file=/dev/null --srcdir=. --no-create --no-recursion ;;
  +    echo "running ${CONFIG_SHELL-/bin/sh} ./configure  --no-create --no-recursion"
  +    exec ${CONFIG_SHELL-/bin/sh} ./configure  --no-create --no-recursion ;;
     -version | --version | --versio | --versi | --vers | --ver | --ve | --v)
       echo "./config.status generated by autoconf version 2.13"
       exit 0 ;;
  
Both were generated by the same version of autoconf:
  $ grep "generated.*autoconf" config.status /tmp/working/lisp/config.status
  config.status:    echo "./config.status generated by autoconf version 2.13"
  /tmp/working/lisp/config.status:    echo "./config.status generated by autoconf version 2.13"

I don't see any significant differences, and in fact executing the
working config.status in the failing directory, then typing "make"
still fails.
  
Comparing the two versions of Makefile.in shows:
  
  $ diff -u /tmp/working/lisp/Makefile.in Makefile.in
  --- /tmp/working/lisp/Makefile.in       2004-04-10 10:55:38.000000000
      -0400
  +++ Makefile.in 2004-04-10 10:55:47.000000000 -0400
  @@ -38,7 +38,7 @@
   pkglibdir = $(libdir)/@PACKAGE@
   pkgincludedir = $(includedir)/@PACKAGE@
  
  -top_builddir = ..
  +top_builddir = .
...
  @@ -168,13 +221,14 @@
   install-am: all-am
          @$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
   install: install-am
  -uninstall-am: uninstall-local
  +uninstall-am: uninstall-INSTALLLISP uninstall-local
   uninstall: uninstall-am
  -all-am: Makefile
  +all-am: Makefile $(LISP)
   all-redirect: all-am
   install-strip:
          $(MAKE) $(AM_MAKEFLAGS) AM_INSTALL_PROGRAM_FLAGS=-s install
   installdirs:
  +       $(mkinstalldirs)  $(DESTDIR)$(INSTALLdir)
  
  
   mostlyclean-generic:

The initial lines of the files are the same, so the same version
of automake created both files.

Although I've made some progress, I do not understand what happened
here.  The first time, I had started in the top directory, _not_ in
lisp/.

For what it's worth, here are my default program versions:

  $ aclocal --version
  aclocal (GNU automake) 1.4-p6
  ...
  $ automake --version
  automake (GNU automake) 1.4-p6
  ...
  $ autoconf --version
  Autoconf version 2.13
  
However, I do have other versions installed:
  $ ls /usr/bin/auto{make,conf}*
  /usr/bin/autoconf	   /usr/bin/autoconf2.50  /usr/bin/automake-1.7
  /usr/bin/autoconf-wrapper  /usr/bin/automake
  /usr/bin/autoconf2.13	   /usr/bin/automake-1.4

	- Jim Van Zandt

--------------------  failing version of Makefile  -----------------
# Makefile.in generated automatically by automake 1.4-p6 from Makefile.am

# Copyright (C) 1994, 1995-8, 1999, 2001 Free Software Foundation, Inc.
# This Makefile.in is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.

# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
# PARTICULAR PURPOSE.


SHELL = /bin/sh

srcdir = .
top_srcdir = .

prefix = /usr/local
exec_prefix = ${prefix}

bindir = ${exec_prefix}/bin
sbindir = ${exec_prefix}/sbin
libexecdir = ${exec_prefix}/libexec
datadir = ${prefix}/share
sysconfdir = ${prefix}/etc
sharedstatedir = ${prefix}/com
localstatedir = ${prefix}/var
libdir = ${exec_prefix}/lib
infodir = ${prefix}/info
mandir = ${prefix}/man
includedir = ${prefix}/include
oldincludedir = /usr/include

DESTDIR =

pkgdatadir = $(datadir)/gnuplot-mode
pkglibdir = $(libdir)/gnuplot-mode
pkgincludedir = $(includedir)/gnuplot-mode

top_builddir = .

ACLOCAL = aclocal-1.4
AUTOCONF = autoconf
AUTOMAKE = automake-1.4
AUTOHEADER = autoheader

INSTALL = /usr/bin/install -c
INSTALL_PROGRAM = ${INSTALL} $(AM_INSTALL_PROGRAM_FLAGS)
INSTALL_DATA = ${INSTALL} -m 644
INSTALL_SCRIPT = ${INSTALL}
transform = s,x,x,

NORMAL_INSTALL = :
PRE_INSTALL = :
POST_INSTALL = :
NORMAL_UNINSTALL = :
PRE_UNINSTALL = :
POST_UNINSTALL = :
host_alias = 
host_triplet = @host@
CC = @CC@
DVIPS = dvips
EMACS = emacs
HAVE_LIB = @HAVE_LIB@
INFO_LOOK_ELC = 
INSTALL_LISP = install-lisp
LATEX = latex
LIB = @LIB@
LISPFILES = elcs
LTLIB = @LTLIB@
MAKEINFO = /usr/bin/makeinfo
PACKAGE = gnuplot-mode
PDFLATEX = pdflatex
VERSION = 0.6.0
lispdir = $(prefix)/share/emacs/site-lisp

AUTOMAKE_OPTIONS = foreign 1.2h

ELS = gnuplot-gui.el gnuplot.el info-look.20.2.el info-look.20.3.el
ELCS = gnuplot.elc gnuplot-gui.elc 
EXTRA_DIST = dot.el dotemacs gnuplot.el.old gpelcard.dvi gpelcard.pdf gpelcard.ps gpelcard.tex $(ELS)

CLEANFILES = $(ELCS) gpelcard.pdf gpelcard.ps gpelcard.dvi gpelcard.log gpelcard.aux
DISTCLEANFILES = info-look.el

BYTEC = $(EMACS) -batch -q -no-site-file -l $(srcdir)/dot.el -f batch-byte-compile

SUFFIXES = .el .elc .pdf .ps .tex
ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
mkinstalldirs = $(SHELL) $(top_srcdir)/mkinstalldirs
CONFIG_CLEAN_FILES = 
CFLAGS = @CFLAGS@
COMPILE = $(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
CCLD = $(CC)
LINK = $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(LDFLAGS) -o $@
LISP =  $(INSTALL_LISP)

DIST_COMMON =  README COPYING ChangeLog INSTALL Makefile.am Makefile.in \
aclocal.m4 configure configure.in install-sh missing mkinstalldirs


DISTFILES = $(DIST_COMMON) $(SOURCES) $(HEADERS) $(TEXINFOS) $(EXTRA_DIST)

TAR = tar
GZIP_ENV = --best
all: all-redirect
.SUFFIXES:
.SUFFIXES: .el .elc .pdf .ps .tex
$(srcdir)/Makefile.in: Makefile.am $(top_srcdir)/configure.in $(ACLOCAL_M4) 
	cd $(top_srcdir) && $(AUTOMAKE) --foreign Makefile

Makefile: $(srcdir)/Makefile.in  $(top_builddir)/config.status $(BUILT_SOURCES)
	cd $(top_builddir) \
	  && CONFIG_FILES=$@ CONFIG_HEADERS= $(SHELL) ./config.status

$(ACLOCAL_M4):  configure.in 
	cd $(srcdir) && $(ACLOCAL)

config.status: $(srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
	$(SHELL) ./config.status --recheck
$(srcdir)/configure: $(srcdir)/configure.in $(ACLOCAL_M4) $(CONFIGURE_DEPENDENCIES)
	cd $(srcdir) && $(AUTOCONF)

install-INSTALLLISP: $(INSTALL_LISP) $(ELCFILES)
	@$(NORMAL_INSTALL)
	@if test -n "$(lispdir)"; then \
	  $(mkinstalldirs) $(DESTDIR)$(INSTALLdir); \
	  list='$(INSTALL_LISP)'; for p in $$list; do \
	    if test -f "$$p"; then d= ; else d="$(srcdir)/"; fi; \
	    echo " $(INSTALL_DATA) $$d$$p $(DESTDIR)$(INSTALLdir)/$$p"; \
	    $(INSTALL_DATA) $$d$$p $(DESTDIR)$(INSTALLdir)/$$p; \
	    if test -f $${p}c; then \
	      echo " $(INSTALL_DATA) $${p}c $(DESTDIR)$(INSTALLdir)/$${p}c"; \
	      $(INSTALL_DATA) $${p}c $(DESTDIR)$(INSTALLdir)/$${p}c; \
	    else : ; fi; \
	  done; \
	else : ; fi

uninstall-INSTALLLISP:
	@$(NORMAL_UNINSTALL)
	@if test -n "$(lispdir)"; then \
	  list='$(INSTALL_LISP)'; for p in $$list; do \
	    rm -f $(DESTDIR)$(INSTALLdir)/$$p $(DESTDIR)$(INSTALLdir)/$${p}c; \
	  done; \
	else : ; fi
tags: TAGS
TAGS:


distdir = $(PACKAGE)-$(VERSION)
top_distdir = $(distdir)

# This target untars the dist file and tries a VPATH configuration.  Then
# it guarantees that the distribution is self-contained by making another
# tarfile.
distcheck: dist
	-rm -rf $(distdir)
	GZIP=$(GZIP_ENV) $(TAR) zxf $(distdir).tar.gz
	mkdir $(distdir)/=build
	mkdir $(distdir)/=inst
	dc_install_base=`cd $(distdir)/=inst && pwd`; \
	cd $(distdir)/=build \
	  && ../configure --srcdir=.. --prefix=$$dc_install_base \
	  && $(MAKE) $(AM_MAKEFLAGS) \
	  && $(MAKE) $(AM_MAKEFLAGS) dvi \
	  && $(MAKE) $(AM_MAKEFLAGS) check \
	  && $(MAKE) $(AM_MAKEFLAGS) install \
	  && $(MAKE) $(AM_MAKEFLAGS) installcheck \
	  && $(MAKE) $(AM_MAKEFLAGS) dist
	-rm -rf $(distdir)
	@banner="$(distdir).tar.gz is ready for distribution"; \
	dashes=`echo "$$banner" | sed s/./=/g`; \
	echo "$$dashes"; \
	echo "$$banner"; \
	echo "$$dashes"
dist: distdir
	-chmod -R a+r $(distdir)
	GZIP=$(GZIP_ENV) $(TAR) chozf $(distdir).tar.gz $(distdir)
	-rm -rf $(distdir)
dist-all: distdir
	-chmod -R a+r $(distdir)
	GZIP=$(GZIP_ENV) $(TAR) chozf $(distdir).tar.gz $(distdir)
	-rm -rf $(distdir)
distdir: $(DISTFILES)
	-rm -rf $(distdir)
	mkdir $(distdir)
	-chmod 777 $(distdir)
	here=`cd $(top_builddir) && pwd`; \
	top_distdir=`cd $(distdir) && pwd`; \
	distdir=`cd $(distdir) && pwd`; \
	cd $(top_srcdir) \
	  && $(AUTOMAKE) --include-deps --build-dir=$$here --srcdir-name=$(top_srcdir) --output-dir=$$top_distdir --foreign Makefile
	@for file in $(DISTFILES); do \
	  d=$(srcdir); \
	  if test -d $$d/$$file; then \
	    cp -pr $$d/$$file $(distdir)/$$file; \
	  else \
	    test -f $(distdir)/$$file \
	    || ln $$d/$$file $(distdir)/$$file 2> /dev/null \
	    || cp -p $$d/$$file $(distdir)/$$file || :; \
	  fi; \
	done
info-am:
info: info-am
dvi-am:
dvi: dvi-am
check-am: all-am
check: check-am
installcheck-am:
installcheck: installcheck-am
install-exec-am:
install-exec: install-exec-am

install-data-am: install-INSTALLLISP
	@$(NORMAL_INSTALL)
	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
install-data: install-data-am

install-am: all-am
	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
install: install-am
uninstall-am: uninstall-INSTALLLISP uninstall-local
uninstall: uninstall-am
all-am: Makefile $(LISP)
all-redirect: all-am
install-strip:
	$(MAKE) $(AM_MAKEFLAGS) AM_INSTALL_PROGRAM_FLAGS=-s install
installdirs:
	$(mkinstalldirs)  $(DESTDIR)$(INSTALLdir)


mostlyclean-generic:

clean-generic:
	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)

distclean-generic:
	-rm -f Makefile $(CONFIG_CLEAN_FILES)
	-rm -f config.cache config.log stamp-h stamp-h[0-9]*
	-test -z "$(DISTCLEANFILES)" || rm -f $(DISTCLEANFILES)

maintainer-clean-generic:
mostlyclean-am:  mostlyclean-generic

mostlyclean: mostlyclean-am

clean-am:  clean-generic mostlyclean-am

clean: clean-am

distclean-am:  distclean-generic clean-am distclean-local

distclean: distclean-am
	-rm -f config.status

maintainer-clean-am:  maintainer-clean-generic distclean-am
	@echo "This command is intended for maintainers to use;"
	@echo "it deletes files that may require special tools to rebuild."

maintainer-clean: maintainer-clean-am
	-rm -f config.status

.PHONY: uninstall-INSTALLLISP install-INSTALLLISP tags distdir info-am \
info dvi-am dvi check check-am installcheck-am installcheck \
install-exec-am install-exec install-data-am install-data install-am \
install uninstall-local uninstall-am uninstall all-redirect all-am all \
installdirs mostlyclean-generic distclean-generic clean-generic \
maintainer-clean-generic clean mostlyclean distclean maintainer-clean


.el.elc:
	$(BYTEC) $<

.dvi.ps:
	$(DVIPS) -o $@ $<

.tex.dvi:
	$(LATEX) $<

.tex.pdf:
	$(PDFLATEX) $<

all: elcs

elcs: $(ELCS)

noelcs:

pdf: gpelcard.pdf
ps: gpelcard.ps

install-data-hook: install-lisp

install-lisp: install-els install-elcs
install-nolisp:

install-els: $(ELS)
	$(mkinstalldirs) $(DESTDIR)$(lispdir)
	@for p in $(ELS) ; do \
	  echo " $(INSTALL_DATA) $$p $(DESTDIR)$(lispdir)/$$p"; \
	  $(INSTALL_DATA) $$p $(DESTDIR)$(lispdir)/$$p; \
	done

install-elcs: $(ELCS)
	$(mkinstalldirs) $(DESTDIR)$(lispdir)
	@for p in $(ELCS) ; do \
	  echo " $(INSTALL_DATA) $$p $(DESTDIR)$(lispdir)/$$p"; \
	  $(INSTALL_DATA) $$p $(DESTDIR)$(lispdir)/$$p; \
	done

uninstall-local:
	@$(NORMAL_UNINSTALL)
	@for p in $(ELCS) $(ELS) ; do \
	  rm -f $(DESTDIR)$(lispdir)/$$p; \
	done

distclean-local:
	@if test "$(top_srcdir)" != "$(top_builddir)" ; then \
	  rm -f gnuplot.el gnuplot-gui.el gpelcard.tex ; \
	fi

# Tell versions [3.59,3.63) of GNU make to not export all variables.
# Otherwise a system limit (for SysV at least) may be exceeded.
.NOEXPORT:

Re: Ready for wrap-up everyone?

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

On Fri, 9 Apr 2004, Petr Mikulik wrote:

> What is "Bruce Ravel's gnuplot-mode distribution"? An old binary
> distribution for Windows? Why it contains info file then?

See the final paragraph of INSTALL.  gnuplot-mode used to be part of
gnuplot itself, then it was taken up and developed into a standalone
package by Bruce Ravel.  Lars has integrated a copy of Bruce's work into
the 3.8 series, which has become the 'lisp' subdirectory of gnuplot.

> I don't see this text relevant for gnuplot 4.0. I don't think it has to
> be "README.1st".

It may not have to be in README.1st, but it does have to be somewhere.

> That an impatient user would go and edit something in term.h.

Well, believe it or not, there are indeed cases where people would and
should do that.  We have autoconf choices mainly for those terminals that
require external libraries, but there are quite a number of others for
which the canonical way to disable them *is* to directly edit term.h

> And if you install gd library, you will no get gif support nowadays -- as
> said in FAQ.

And in README.1st.  Which, as it's name says, people are supposed to have
looked into before they read INSTALL.

> > > Also, README.1ST speaks only about GIFs. What about deleting this file
> > > and reference from README to FAQ?
> >
> > README.1st is the first-stop README file for the source distribution.
> > It's not even necessarily being distributed with binary distributions.
> 
> It's nowhere written why and why should read this document.

~The name explains that by itself.  "Read me first!".  That's about the
most obvious you can get.

> For source distribution, one should read INSTALL. 

*After* reading README.1st.  And README.1st should say so.  It will ---
I'm working on it.


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

Re: TODO

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

> > version, but the distributors won't necessarily know which files these
> > are. I would *hope* they at least think to install the demo files, but
> > they may not know to first run 'make' in the demo directory to generate
> > binary data files.

Yes, if there is no "make" option to install all files *we* think should
belong to a complete gnuplot distribution, then we can expect every linux
distribution and will be different. Why somebody else should know whether
e.g. tutorial is useful for users or not?

> They don't have to --- running 'make' in the main directory is perfectly
> sufficient.  If they don't know how to build a fully autoconf/automake
> wrapped package like gnuplot, they're in the wrong business pretending to
> be a Linux distributor anyway.

No, "make install" is not sufficient. For example, compares its result to
that of my binary releases. There is no such "make install blabla" I guess.

> > The pm3d/contrib directory?

Hmm I would also like to know how to organize them better -- or put to web?
I thought gnuplot could be distributed with a library of useful scripts, but
nobody has proposed such a structure.

> > The old README.* files?

Should be merged with gnuplot.doc and INSTALL, or to web.

I've done this for OS/2-related documentation and some others. Maybe someone
could continue with other files? Some info (like from 3D data) would be much
more useful to be in gnuplot.doc.

> > The tutorial?

I've upgraded it for 4.0.

> If we want to give them a hand explaining them what we would like them
> to put in their binary packages --- fine, add a paragraph to INSTALL
> about that.

make completeinstall  ??

> OTOH, why should we expect them to put stuff in there that our
> own 'make install' doesn't put up anywhere?

Exactly.

---
PM

Re: Ready for wrap-up everyone?

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

> > >  Note 3
> > >  ------
> > >  some files from Bruce Ravel's gnuplot-mode distribution have
> > >    not been included here, namely
> > >
> > >    o INSTALL              (covered by gnuplot install instructions)
> > >    o Win9x/INSTALL.Win9x
> > >    o Win9x/pgnuplot.c     (already in src/win)
> > >    o gnuplot.info         (can be created from docs/gnuplot.texi)
> > >    o gpelcard.ps          (can be created from lisp/gpelcard.tex)
> > >    o install-sh, mkinstalldirs  (provided by gnuplot)
> >
> >
> > I don't understand what this text tries to say nowadays. Therefore I propose
> > to delete it.
>
> Deleting what you don't understand might be dangerous.  I think it really
> should stay.

What is "Bruce Ravel's gnuplot-mode distribution"? An old binary
distribution for Windows? Why it contains info file then?

I don't see this text relevant for gnuplot 4.0. I don't think it has to be
"README.1st".


> [Note this is from INSTALL, and it goes under the heading "For the
> impatient."  This is not the principal installation instruction.]
>
> > First, tune term.h to choose which terminal drivers you wish to enable.
> > If you want to support gif output, you need to download, compile and
> > install the gd library : see term/gif.trm for details.
>
> > I don't think that's like that.
>
> What exactly in this do you think is "not like that"?

That an impatient user would go and edit something in term.h.

And if you install gd library, you will no get gif support nowadays -- as
said in FAQ.


> > Also, README.1ST speaks only about GIFs. What about deleting this file
> > and reference from README to FAQ?
>
> README.1st is the first-stop README file for the source distribution.
> It's not even necessarily being distributed with binary distributions.

It's nowhere written why and why should read this document.

For source distribution, one should read INSTALL. And that first paragraph
of of README.1ST is duplicated in section "For impatient user".

And README.1ST also writes how to convert images into gif -- i.e. user-space
utilities.

So the information there is a mess. I propose to delete the file completely,
unless someone gives it a sense.

---
PM

Re: TODO

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

On Thu, 8 Apr 2004, Ethan Merritt wrote:

> version, but the distributors won't necessarily know which files these
> are. I would *hope* they at least think to install the demo files, but
> they may not know to first run 'make' in the demo directory to generate
> binary data files.

They don't have to --- running 'make' in the main directory is perfectly
sufficient.  If they don't know how to build a fully autoconf/automake
wrapped package like gnuplot, they're in the wrong business pretending to
be a Linux distributor anyway.

> The pm3d/contrib directory?  
> The old README.* files?
> The tutorial?
> ps_guide.ps?

If we want to give them a hand explaining them what we would like them
to put in their binary packages --- fine, add a paragraph to INSTALL
about that.  

OTOH, why should we expect them to put stuff in there that our
own 'make install' doesn't put up anywhere?

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

Re: TODO

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

On Thursday 08 April 2004 04:00 pm, you wrote:
> If RPM or .spec files really were compatible between a large
> subset of the major distros, it might be worth it, but AFAIK, they're
> not. I see no reason why we should do the distributor's work for them.

Right. But a key part of the spec file in any case is simply a list of
the files that should be installed.  There may be files in the source
tree that we think should be kept for user reference in the installed
version, but the distributors won't necessarily know which files these
are. I would *hope* they at least think to install the demo files, but
they may not know to first run 'make' in the demo directory to generate
binary data files.
The pm3d/contrib directory?  
The old README.* files?
The tutorial?
ps_guide.ps?

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

Re: TODO

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

On Thu, 8 Apr 2004, Ethan Merritt wrote:

> On Thursday 08 April 2004 09:46 am, Petr Mikulik wrote:
> > Please have a look to that file...
> 
> BUGS - maybe just refer people to the bug-tracker on 
> SourceForge.

Not unless we file all the bugs currently in there into the Tracker first.  
For the moment, I guess we should err toward the lazy option and just keep
it as it is.  It's short, and the Bug Tracker is mentioned prominently.

> I think all those docs/old/README.* files can be deleted.

No.  At least some of these files are a significant part of the legacy of
gnuplot.  Pretending all that history never happened would be the wrong
thing to do at this time, IMHO.

In what little time is left, I suggest we concentrate our efforts on those
things that really *need* improvement.  Removing stale stuff should be
postponed to the general house-cleaning session we'll have to do right
after the release anyway.

> The mention of an INF bug for binary files- I'm not sure.
> I can't find any record of such a bug on the SourceForge bug list.

There was a bug with reading Inf and NaN's from ordinary data files which
I fixed pretty recently (2004-03-04).  I guess that will plug this one,
too, because the fix works one level above the datafile reading.

I'll delete this from TODO.  If it's an actual bug, somebody should file
it at SF.net.

> A linux rpm - hmm.  I think the distros will probably do that to
> suit themselves.  If necessary I can make a Mandrake rpm.
> that might or might not work under other rpm-based distros.

Making our own binary packages for Linux distros would be waste of effort.  
They'll all make their own ones anyway, eventually, so whatever we do
would be obsolete with the next distribution release (if not earlier).  
If RPM or .spec files really were compatible between a large subset of the
major distros, it might be worth it, but AFAIK, they're not. I see no
reason why we should do the distributor's work for them.

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

Re: Ready for wrap-up everyone?

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

On Thu, 8 Apr 2004, Petr Mikulik wrote:

> > *) File README.1st:
> >
> > This text is to be deleted?
> >
> >  Note 3
> >  ------
> >  some files from Bruce Ravel's gnuplot-mode distribution have
> >    not been included here, namely
> >
> >    o INSTALL              (covered by gnuplot install instructions)
> >    o Win9x/INSTALL.Win9x
> >    o Win9x/pgnuplot.c     (already in src/win)
> >    o gnuplot.info         (can be created from docs/gnuplot.texi)
> >    o gpelcard.ps          (can be created from lisp/gpelcard.tex)
> >    o install-sh, mkinstalldirs  (provided by gnuplot)
> 
> 
> I don't understand what this text tries to say nowadays. Therefore I propose
> to delete it.

Deleting what you don't understand might be dangerous.  I think it really 
should stay.

> And what about this text:

[Note this is from INSTALL, and it goes under the heading "For the
impatient."  This is not the principal installation instruction.]

> First, tune term.h to choose which terminal drivers you wish to enable.
> If you want to support gif output, you need to download, compile and
> install the gd library : see term/gif.trm for details.

> I don't think that's like that.

What exactly in this do you think is "not like that"?

> Also, README.1ST speaks only about GIFs. What about deleting this file
> and reference from README to FAQ?

README.1st is the first-stop README file for the source distribution.
It's not even necessarily being distributed with binary distributions.

It should point at INSTALL, though.  And it's probably also the place
where we should explain the situation with PDFlib (or at least mention
it and refer to INSTALL for the details.


> Note that the new gnuplot web page does neither speak about gifs.
>
> ---
> PM
>
>
>

> 
> First, tune term.h to choose which terminal drivers you wish to enable.
> If you want to support gif output, you need to download, compile and
> install the gd library : see term/gif.trm for details.

> I don't think that's like that.

What e
> 
> Also, README.1ST speaks only about GIFs. What about deleting this file and
> reference from README to FAQ?
> 
> Note that the new gnuplot web page does neither speak about gifs.
> 
> ---
> PM
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 
> 

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