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

Reply via email to