Hi Alan, > > Hazen, I would advise avoiding all that pain by sticking with just > distributing a binary version of PLplot without the external > dependencies.
Nope, not a good idea. Although most dlls are loaded on demand (with the driver dll) it's just not the way a Windows user wants to have a binary of a library. So you would provide a binary which is just broken, since dll dependencies are missing. You await that the user is downloading 6 other libraries on its own, just to make plplot work. Sorry, but Windows is working different. There is not apt-get or yum which just solves these dependency issues for you. I would just provide a binary which has everything in it (this is what is "usual" in the windows world). E.g. the QT SDK provides lot of libraries which are not by Qt/Nokia (e.g. libpng, webkit and dozens others). They don't assume, that you compile webkit on your own (which is close to impossible ;). We could provide several plplot distributions, e.g. one which has only the wingcc driver in and all other devices which are easy to compile (png, svg, ect.) and one heavy binary with qt and others. And exactly here is the point where my script comes in handy. To answer you earlier message, cpack would be perfect, but you need to copy the necessary dlls in afterwards into the zip file. But Cpack doesn't compile other dependencies. And actually my script is not about to replace cpack. The aim of the script is to provide a "standard" development environment where all libraries are downloaded and compiled with known parameters. Then plplot is compiled and cpack can be used to make the package. The script can then copy the missing dlls into the zip. I know this is completely different to Linux, but in Linux one has problems with a certain library you ask him which version he has and if he used apt-get. If Hazen compiles the qhull library and uses it and after one year I have problem with that library and I ask him how he compiled the library, he may not know. It may even a problem with two or more version of the same library being available on the same system (which happens often) and then you use the wrong library without knowing that. Using a script you provide all the libraries and you are *sure* that these libraries are used. I'm feeling quite strong about that issue, since I had all these problems the last 10 years I developed on Windows machines, and such scripts I use often in my projects and made my life much easier especially working with other developers, since they then use also the same "standard" development environment. Werner > That is hard enough already because I just realized you are going to > have to > think carefully about the 64-bit versus 32-bit issue. I notice, for > example, that on the Qt binary download page there are 64-bit and 32 > bit > Linux versions but no such separation for Mac OS X and Windows. > It's quite > possible that means those OS's deal with 32-bit versus 64-bit > automagically. > OTOH, there may be an assumption or de facto standard that all binary > distributions for those OS's are 32-bit. I don't know. > > BTW, I think there has been an attempt by some Linux distributions to > support mixed 32-bit and 64-bit systems. I don't know whether that > effort > is continuing, but I am very happy with my pure 64-bit system for > Debian, > and I wouldn't want the heachaces of mixing in some 32-bit apps and > libraries. > > 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); PLplot scientific plotting > software > package (plplot.org); 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 > __________________________ -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria DVR-Nr: 0005886 email: sme...@iap.tuwien.ac.at web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
