octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Another FLTK/gnuplot divergence


From: Rik
Subject: Re: Another FLTK/gnuplot divergence
Date: Fri, 27 Sep 2013 12:37:40 -0700

On 09/27/2013 10:15 AM, Mike Miller wrote:
> On Fri, Sep 27, 2013 at 09:26:42 -0700, Rik wrote:
>> I take your point, although automated builds of tarballs (such as for a
>> downstream package maintainer like Debian) would still work in all cases
>> because the images are shipped with the code.
> True, unless a file is patched, deleted, or touched to force a
> rebuild, intentionally or otherwise.
The images are not quite like ordinary files.  You can change most Octave
files, including changes that force a rebuild of the manual, as long as the
scripts that generate the images, such as geometryimages.m, are not
modified.  There is no reason downstream should modify these, and if they
do they are welcome to the consequences.
>
>> It would only be an
>> automated build server like Hydra, which is operating directly from the
>> Mercurial sources, that would have a problem.
> Yeah that's the case I thought of first. It could also be any
> developer or user working from mercurial that builds with some kind of
> automated background script, works on a headless server, or over an
> SSH tunnel with no X.
>
> The best policy is to not assume a display until the user specifically
> requests a plot, and keep gnuplot for building the docs until we have
> native plotting that can render offscreen.
>
Support for offscreen images in opengl2ps does not look forthcoming anytime
soon so we may have to revisit this.  However, for the moment we definitely
need gnuplot since it can render TeX strings from the print() command.

--Rik


reply via email to

[Prev in Thread] Current Thread [Next in Thread]