Re: gnuplot-4.2.rc1: --program-suffix and gnuplot_x11

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

On Thursday 05 October 2006 12:07 pm, Daniel J Sebald wrote:
>  > I just leave the patched executable in the patched source
>  > directory where it was built, and setenv GNUPLOT_DRIVER_DIR
>  > to point there if I want to test it.
>
> but that isn't exactly the most proficient method.  I'd have to keep
> changing GNUPLOT_DRIVER_DIR if I want to alternate between "gnuplot"
> and "mygnuplot"

Huh?  We're talking about gnuplot_x11, not gnuplot.  It doesn't
make any difference which gnuplot executable you are using.

> From the standpoint of a multiuser environment like a computer
> center

Stop right there. The issue is not multi-user; the issue is
multiple machines seen by *one* user.

I have two different machines at my desk (x86 and amd64) and
have gnuplot installed also on 64-bit alpha and both 
32- and 64- bit irix machines on the same network. 
Various windows on my desktop may be logged in to various of
these machines.  Fun, huh?   

And if my login directory is shared via NFS by some or all of
these architectures, then the appropriate run path has to
be constructed every time I log in, since if I log in on 
a 32-bit Irix workstation the 64-bit linux executable isn't
going to do me much good.

The last thing I want is to have to remember to type
gnuplot_amd64 instead of gnuplot_irix5 depending on which
machine is listening to the window I'm typing into.
The name should always be "gnuplot", and the path should make
it 'just work'.

> One other comment is that I've tended to not so much think of
> gnuplot_x11 as being a separate program.  If we are at the point of
> considering gnuplot-x11 running on one machine and gnuplot on
> another, it might then be pertinent to start talking version numbers
> and having gnuplot check that its version is compatible with the
> gnuplot_x11 version.

That's a totally separate issue.
Version mis-match is already a problem on a single machine.
Usually you get an error message "gnuplot_x11: protocol error",
which isn't so bad as error messages go.



>
> Dan
>
> Ethan Merritt wrote:
> > I don't think this is the right approach, because it does
> > not truly allow for the general case of a mixed architecture
> > environment.  What if gnuplot_x11 is running on a different
> > machine than gnuplot?  What if gnuplot was built 64-bit, but
> > gnuplot_x11 was built 32-bit?
> >
> > What I have seen work for other program packages is to leave
> > the name of the executable unchanged, but install multiple
> > architecture-specific executables into parallel directories.
> > The correct executable is selected by virtue of the PATH
> > set for your current session. In the case of gnuplot you
> > could also use the GNUPLOT_DRIVER_DIR environmental variable
> > to control this, but you'd have to set it in an
> > architecture-dependent fashion via your login script.
> >
> > In other words, if we are to do this at all, I think the
> > correct approach is to leave the file name of gnuplot_x11
> > unchanged, but teach the install procedure to create a
> > directory name from the architecture type.  Or just add
> > a set of instructions for manual installation of this
> > one component in a mixed-architecture environment.
> >
> >>In my case, I used --program-suffix for a multi-architecture build.
> >>But previously I also used --program-suffix="-patched" to
> >> distinguish my modified version from the upstream version.  IIRC I
> >> also had to symlink gnuplot_x11 accordingly back then.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA