Hi Alan, > > 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/).
Sure, but Windows is not POSIX OS and it's difficult to port all the programs. gnuwin32 and mingwPORT don't cover everything just some selected programs and cygwin has other disadvantages (e.g. doesn't "fit" well into windows. It's a good idea many people had before (apt- get would be great for Windows) but we won't be able to change that. > > 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. I already had a look into this months ago, but it's not "straight- forward". But I agree 100% with you, that this is a necessary step to take. People who want to try out plplot likely might have experiences with cygwin already and installing plplot with cygwin would just be a "piece-of-cake". I hope that I can make such a port anytime in the future (if somebody else does that the better). > > 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). Good idea. maybe not installing all the packages into the install tree, because this would make the package huge, but only the dlls. > > 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 know, but as you say, you just need to provide a link to the source packages. We could upload the packages on my webpage where the wiki is - this is also the way I want to go for the script - downloading source code from this webpage, since links might change which would break the script. This way we provide the source code for the script and also not to violate licenses. > > 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. Regards, Werner > > 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 -- 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 ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
