On Tuesday 22 Oct 2013 23:29:40 Andrew Ross wrote:
> On Tuesday 22 Oct 2013 12:58:12 Orion Poplawski wrote:
> > On 10/22/2013 12:19 PM, Alan W. Irwin wrote:
> > > One other issue I noticed this morning is that the shared object
> > > plplot_octave.oct is installed in
> > > $prefix/share/plplot_octave/plplot_octave.oct. I am positive
> > > rpmlint will start complaining about the install location of that
> > > file once its permissions are executable. I assume it should
> > > go somewhere in the $prefix/lib tree instead.
> >
> > On Fedora it installs to:
> >
> > %{_libdir}/octave/site/oct/*/plplot_octave.oct
> >
> > with no trouble on my side, so I think we are okay at least on Fedora. I
> > think it gets the path from the octave.
> >
> > > @Andrew:
> > >
> > > Would $prefix/lib/octave/plplot_octave.oct be a better location, and
> > > if so, would you take responsibility for fixing it please? Assuming
> > > you do decide to change the location, there will be a number of issues
> > > for that changed location revealed by the shared/dynamic devices
> > > subset of scripts/comprehensive_test.sh. That script runs both
> > > non-interactive and interactive tests for the build tree, and the two
> > > different build systems for the installed examples, and it will be a
> > > matter of knocking off those issues one by one as you find them via
> > > those comprehensive tests.
>
> Yes it would be a better location. For the Debian packages I override the
> default anyway. On Ubuntu and Debian (which are now multilib aware) octave
> files gets installed to /usr/lib/ARCH/octave/site/oct/*/plplot_octave.oct
> where ARCH is something like x86_64-linux-gnu as in Fedora. Actually on
> Debian it should probably be in
> /usr/lib/ARCH/octave/packages/plplot-5.8.10/ or similar.
>
> I'll look into changing the default so the plplot_octave.oct file is
> installed in $prefix/lib/octave/. The .oct files are loaded by octave, not
> the plplot code so we just need to ensure that the octave path is set
> correctly.
Turns out to be a one line fix as all the infrastructure is already there. The
current behaviour is to use the octave configured directory for .oct file if
the
plplot install prefix is the same as the octave install prefix. If not, then
install in ${CMAKE_INSTALL_DATADIR}/plplot_octave , which is clearly wrong as
these are binary files. New behaviour changes CMAKE_INSTALL_DATADIR to
CMAKE_INSTALL_LIBDIR.
We _could_ adopt what we do for the .m files, which is to take the octave
configured directory, strip off the octave install prefix and add the plplot
install prefix. This may be unduly complicated. On my Ubuntu system this would
result in .oct files going in ${CMAKE_INSTALL_PREFIX}/lib/x86_64-linux-
gnu/octave/site/oct/x86_64-pc-linux-gnuoctave . The architecture dependent
directories are a result of Ubuntu (and Debian) supporting multiple
architectures on the same system (e.g. both 32 and 64 bit versions of
libraries etc).
Andrew
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel
