Re: [Plplot-general] Trying to build examples

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

On 2015-01-22 12:39-0000 Schwartz, Steven J wrote:

> Dear All,
>
> Alan W. Irwin wrote on 2015-01-22:
> ----------------
>
>> On 2015-01-22 10:35+0100 Arnaud Darmont wrote:
>>
>>> We are not going to deploy anything like this on our customer's
>> machines. It has to run in a windows install without any specific
>> external requirements.
>
> Somewhere along the execution path all code must talk to the operating system. I don't think it's possible to protect your code completely from its environment.
>
>> For others reading this thread now or in the future, it is not quite that simple.
>> I think every good plotting package worth its salt has external
>> libraries it depends on so the static linking method I described
>> earlier in this thread must be used to avoid deployment issues.  So
>> Arnaud's real complaint against PLplot is he would have to figure out
>> how to statically link PLplot against static external libraries with
>> some of that work requiring CMake investigation. And that is certainly a valid complaint.
>
> Just a note here that we distribute dynamically linked Windows binaries of our software, which uses plplot dll's for the graphics. I wonder, Alan, if you scared Arnaud by producing a long list of external dependencies (wxwidgets, qt, cairo, shapelib, etc., etc.) required to produce what you regard as a full plplot distribution. We take the minimalist approach. We ship a plplot with only ONE set of drivers, in our case the qt ones because the rest of our application is actually built using qt. But I could imagine building only, say, the wingcc and postscript drivers or whatever, depending on the functionality and quality required for the application. I realise that this is perhaps heresy to the core plplot development team, whom I applaud for an excellent software suite and active support/development, but not all applications have
>
> Our distribution is a simple zip file that unpacks into a hierarchy that contains a lib directory. Into that directory we drop the plplot dll's, the Qt ones, and any others that are not part of the Windows system. We don't use a Windows package installer, but all that would do would edit the batch script to point to the right directory and, I suppose, register the application with the windows registry.
>
> I have used Dependency Walker to interrogate our executable and hence to identify those libraries that we need to include: they are the ones which aren't built specifically by us and aren't found in, e.g. c:\windows\system32. There is a certain amount of manual debugging here to get it right, but I think this is not restricted to the needs of plplot and is part and parcel of a binary distribution. Actually, I've been impressed by how well this works under windows (xp, 7, 8) by comparison with difficulties for even minor changes to a particular flavour or linux or macos.
>
> We don't automate very much here. We don't use CMake to build plplot, but instead build the the plplot core and our own qt driver via an old-fashioned but very transparent build script that builds the rest of our application. Again if you build a minimalist version and if you are shipping a binary, choose whatever approach is most consistent with the rest of your methodology. We also don't follow every plplot upgrade, saving our tiny manpower resource to work on other functionality of our software.
>
> At present, our Windows distribution is built with a relatively old (4.7.2) mingw/MSYS toolchain for which a Qt 4.8 binary build is available, but I have it on my radar to move to MSYS2 and Qt5.
>
> I have made similar points in previous postings on this list, namely the desirability of providing some support and examples to those who wish to use plplot but are more familiar with other build systems - could be anything from gnu configure to qmake to a handmade build shell script to a one line compile command. A simple plplot "hello world" example with instructions on how to write the one-line gcc compile command and what needs to be in the user's PATH would demonstrate some flexibility that some people might find appealing.

Good post, Steve!  I certainly agree that someone with Arnaud's
distribution needs should evaluate PLplot to figure out the minimalist
components of it that they need (since disabling unused components
makes their distribution life much easier).  Such component disabling
is well supported by our current build system, but we likely need to
document that better in our wiki.  In response to your last point, we
do provide two systems (make+pkg-config and CMake) for building our
examples. They both do an awful lot now that is important (such as
implementing tests of the results), but that complexity is likely
confusing to the first-time user so we also need to document in our
wiki a minimalist example or two of how to use both those approaches
to build an app that links to PLplot.

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
__________________________