Re: [Plplot-devel] Fedora plplot patches

[Alan W. I. <ir...@be...>]

Hi Hez:

Can you evaluate Patch7 below that removes the -custom option
from our ocamlc build commands?

@Orion and Andrew: the rest of this response is addressed to you
as our respective Fedora and Debian packagers.

On 2015-04-25 12:42-0600 Orion Poplawski wrote:

> On 04/25/2015 11:05 AM, Alan W. Irwin wrote:
>> While we are at it, are there any other general issues like this one
>> (i.e., issues likely to affect all distros) addressed by the Fedora
>> downstream patches which we should be aware of upstream?
>
> There are two other issues currently addressed downstream, which I'm pretty 
> sure I've raised here before.  The ocaml one relatively recently, not sure 
> about the multiarch one.
>
> Patch2:         plplot-multiarch.patch
>
> This allows for the "core" plplot package to be "multiarch" - exactly the 
> same content for 32-bit and 64-bit builds.  Otherwise the PKG_CONFIG_ENV and 
> RPATH variables have /usr/lib or /usr/lib64 in them.  I know this patch isn't 
> acceptable upstream as it is, but if you found a way to address it, that 
> would be great.

Patch2a: PKG_CONFIG_ENV

I have now (commit id 2b4e397) implemented a user-configurable location called
CMAKE_INSTALL_PKG_CONFIG_DIR where the PLplot *.pc files are
installed.  The default value for this cached variable is

$prefix/share/pkgconfig

which is apparently what Debian wheezy uses for multiarch *.pc files.

@Andrew: can you confirm that location for modern Debian?

@Orion: If that default location is not right for the Fedora multiarch
needs, try setting CMAKE_INSTALL_PKG_CONFIG_DIR on the cmake command
line.

Patch2b: RPATH

Use -DUSE_RPATH=OFF.  This should make all rpath results empty and the
RPATH part of Patch2 redundant.

@Orion:
In sum, with commit id 2b4e397 and the long-implemented USE_RPATH there
should no longer be any need for Patch2.  Please confirm that.

>
> # Don't use -custom with ocamlc
> Patch7:         plplot-ocaml.patch

I have left that patch attached because I don't have any OCaml expertise
to make an informed decision about whether to accept that upstream.
Our OCaml go-to guy here was Hezekiah M. Carty so I have CC'd him in
hopes that he will make the decision.

@ Andrew:
However, Hez has not been in contact for quite a while now so if he
doesn't respond would you be willing to make the decision (since I
believe your OCaml expertise no matter how small is still greater
than my own.  :-) ).

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________