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 __________________________ ------------------------------------------------------------------------------ New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet _______________________________________________ Plplot-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-general
