Re: [Plplot-general] Trying to build examples

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

On 2015-01-21 23:09+0100 Arnaud Darmont wrote:

> Alan,
>
> thank you for the detailed answer. Cmake is what i'm trying to use.
>
> As i understand this won't be easy and i fear that there will be deployment 
> difficulties on customer systems. My goal would be to distribute an 
> executable of the final software along with the source so that they can just 
> run it without any installation. Will in the end PLplot allow for this or is 
> it the wrong library?

I think your first priority should be to get the PLplot build to work
on either Cygwin or MinGW-w64/MSYS2.  Both of those platforms should
provide a full suite of external libraries that PLplot depends upon to
provide complete functionality.  Those external libraries include
libqhull and shapelib (both needed by the core PLplot library for full
functionality), libharu (needed for the pdf device driver), the
wxwidgets library (needed by the PLplot wxwidgets device driver), Qt5
(needed for the qt device driver), and the Pango/Cairo subset of GTK+
(needed for the cairo device driver).  Note, that qt and cairo are
currently our best device drivers, and one of our developers is
working hard to bring our wxwidgets device driver up to that same
level of quality.  I would avoid MinGW/MSYS because it supplies few
libraries and therefore your PLplot build there will generate an
extremely lite version of PLplot that doesn't have the capabilities
(e.g., none of the wxwidgets, qt, or cairo device drivers) provided by
the equivalent PLplot build on those other two Windows platforms.

If you like the PLplot capabilities you find on either Cygwin or
MinGW-w64/MSYS2, then I believe the answer to the deployment issue you
brought up above is to build your software package against a static
version of PLplot (which should be trivial to arrange) which in turn
has been built against static versions of the external libraries
(non-trivial to arrange). If you can do that, it virtually solves your
deployment issues since you don't have to worry about version
incompatibilities of ABI incompatibility issues with shared external
libraries your users may or may not have installed, i.e., no dll-hell
issues.

My understanding is that CMake does have a method to force linking
with static external libraries if they are available rather than
external shared libraries (its default preference).  But I have never
actually tried that myself, and you would likely have to ask on the
CMake list or google for how to do it.

In sum, my advice to solve the deployment issue is to abandon
MinGW/MSYS (due to lack of external libraries) and try either/both
MinGW-w64/MSYS2 or else Cygwin. If satisfied with one of those verify
it has static versions of the necessary external libraries that you
can install.  Then figure out how to convince CMake to preferentially
use static libraries for linking, and build a static version of PLplot
against those external libraries.  Then statically link your software with
that static PLplot for your deployment.

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
__________________________