On 2009-07-26 10:10+0200 Werner Smekal wrote: > 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.
I trust your judgement about what seems normal in the Windows culture, but in my opinion that culture has to change if free software is ever to get anywhere in the Windows world since the "complete" packages are much larger than the have to be. I guess the only way to overthrow this Windows "complete package" culture is to have self-consistent software distributions on Windows like there are on Linux. Cygwin is obviously one example of this, and there are others in a much less complete state such as the mingwPORT effort (http://www.mingw.org/wiki/mingwPORT) and the gnuwin32 effort (http://gnuwin32.sourceforge.net/). Given this situation, one of our binary distribution priorities should be to get PLplot into at least Cygwin. There are all sorts of plotting packages there (including our principal competitor gnuplot), but no PLplot, yet. It would have to be a light-weight version of PLplot without qt, cairo, or wxwidgets (since Qt4, libpango/libcairo, and wxwidgets packages do not exist for Cygwin), but that would at least give Cygwin users an additional good plotting option. So I hope either you or Arjen (our two software developers with current Cygwin experience) of Hazen (who appears to be just getting into Windows) volunteers to be the Cygwin maintainer of PLplot. If in addition we are going to get into the complete binary package business for Windows, I agree with your point above about having both a light-weight and heavy-weight version. > 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. > A separate script would be great to download and build all external libraries that are needed. Once all the dlls were assembled that way by the script, then I would suggest either the script copy them to what will become the install tree before the PLplot build and install or using the CMake install command (guarded by appropriate logic so this only happens when creating a complete binary package for Windows) to copy those dlls into the install tree. CPack just packages up what is in the install tree when creating a binary software package so if you use either of those two alternatives for copying the dlls into the install tree before CPack is run, you would not have to copy the dlls into place after CPack is run (which means you won't have to unpack the binary package, copy to its tree, and repack it again). BTW, one complication of the above "complete binary package" model is you must follow the licensing provisions. That means for LGPL software like pango/cairo and Qt you cannot distribute dll's without also making the source code available. It doesn't have to be part of the binary package, but you do have to provide an equivalent source package (such as RedHat's source rpms that correspond to their binary rpms). There has been a case in the last year where it was proved not enough to simply point to some external site where the source code was available. You have to make GPL and LGPL software source available yourself (like RedHat and all Linux distros do), and there is no way I want PLplot to be even close to any violation of a free software license. I agree with you that complete light-weight and heavy-weight binary package of PLplot will probably be popular on Windows, but in that case you are stuck with the source redistribution of the external (L)GPLed packages as well. However, you might also want to consider an additional option of a "no_external" binary package for PLplot which installs no external libraries, but instead gives the users the above script to build what they need. That option does not require external source distribution since you are not distributing external dll's in that case. Probably most users would prefer the "complete" light-weight or heavy-weight packages (at least to start), but the no_external package costs little to produce compared to the others, and its popularity (as measured by SF download statistics) might surprise us. 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 __________________________ ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
