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. Best wishes Steve -------------------------------------------------------------------- Steven J Schwartz Phone: +44 (0)207 594 7660 Professor of Space Physics Fax: +44 (0)207 594 7772 Director, Imperial Space Lab www.imperial.ac.uk/spacelab The Blackett Laboratory Email: [email protected] Imperial College London Office: Huxley 6M67A London SW7 2AZ, UK Web: www.sp.ph.ic.ac.uk/~sjs -------------------------------------------------------------------- ------------------------------------------------------------------------------ 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
