I agree with Alan's caution over this, however if we _can_ manage a windows binary distribution then that would immeasurably widen the appeal of plplot. The fact is that plplot is a complex beast to build given the dependencies and Windows users tend to be far less used to this kind of thing than Linux users. Even on Linux, the fact that we have packages in the major distributions has certainly widened our user base.
Alan's work looks like a good step in the right direction. Andrew On Monday 24 Jun 2013 12:11:52 Alan W. Irwin wrote: > Hi Arjen: > > This is an extremely interesting topic for me. More below in context. > > On 2013-06-24 14:42+0200 Arjen Markus wrote: > > We have discussed the possibility of binary distributions in the past, > > but there never was an opportunity as far as I remember to really do > > something about it. CMake does come with CPack and that might just be > > the vehicle we could use for this. > > As a proof of concept we have successfully created local binary > distributions of PLplot in the past using the CPack facilities. As I > recall, there is some trick to it because we use absolute rather than > relative installation paths so if you cannot find that trick in our > mailing list archives you might need to ask on the CMake list or look > into the CMake wiki to figure out what to do for absolute installation > paths. But there should be no fundamental technical roadblocks to > creating binary distributions of PLplot right now using the existing > CPack facilities. > > > I think it will fit in smoothly with Alan's work on building the > > external libraries from within the PLplot build system. > > Yes it would. > > > Of course there are many problems to tackle, besides the technical > > ones: > > - What kind of builds would we provide? If only: single or double > > > > precision, what drivers, what languages, etc. > > I have thought about this question for build_projects. What I > will probably configure there is a plplot-lite build (essentially no > dependencies at all other than shapelib and qhull) but which includes > the C++, Fortran 95, and Ada bindings (i.e., all languages supported > by MinGW out of the box) > and a fully configured plplot build that > includes dependencies (and the appropriate builds) of essentially > everything (e.g., Qt4, pango/cairo, wxwidgets, Tcl [but not Tk for > technical reasons we have discussed before]) that we have access to in > the Linux version of PLplot. This one would probably require several > hours to build. The only point of plplot-lite is quick build > times, and if we decide to distribute a binary version of PLplot, I > think the complete version of PLplot (the double precision form > including most device drivers and bindings as is distributed on Linux) > is what we would want to distribute. > > > - How to distribute the packaged versions? Just put them next to > > > > the tarballs with the sources? > > Yes. That is what other projects do (e.g., MinGW) at SourceForge. > > > I would like to examine the questions Clive raised - just a minimal > > package so that he can experiment with PLplot and we with the > > question of packaging. Would this indeed be useful or is it a bad idea > > from the very start? > > There are other issues not covered above which should be considered. > Most of them are straightforward, but I think one of them (security > concerns) is tricky. > > * Our source code distribution obligations under open-source licenses. > Generally according to these licenses, we would have to distribute not > only our binary version, but _all_ the source code that went into > that. Note, this includes the source code of the dependent libraries > that we build as part of our distribution such as Qt4, pango/cairo, > wxwidgets, etc. Large binary distributions are completely permitted > by SourceForge (planetary and time ephemerides distributed by my > timeephem project currently consume more than a Gigabyte of file > space). So technically, all that would be required is for the > build_projects project to preserve and distribute the source code that > it downloads. So it should be entirely straightforward to fulfill > these obligations. > > * Shared libraries versus static. I think static libraries are a > no-brainer on Windows despite the size implications. I think we want > static PLplot libraries and static libraries which PLplot depends on > in our binary distribution so there is no chance of other downloaded > versions of shared libraries interfering with the PLplot binary > distribution results. I haven't implemented this yet, but propagating > the -DBUILD_SHARED_LIBRARIES=OFF cmake command line option to all > built projects is completely straightforward for build_projects. > > * Static run time. I think we want this as well if possible. I > believe this topic has come up recently here, but I don't recall the > conclusion about whether this is feasible. > > * Security concerns. Every large open-source project out there (e.g., > Fedora, Debian, Ubuntu, Linux kernel, and SourceForge itself) have had > completely successful security attacks on them in the last decade > where the attacker ended up completely "owning" the system from hours > to days. To deal with the fallout from these attacks, these big > projects had to do complete forensic analysis of their attacked > systems and were sometimes down for months because of the time that > audit required. > > So security is a major and on-going issue for any binary distributor > of open-source software because the downsides of a security issue are > pretty big. For example, you have to ask yourself, what would it do to > PLplot's reputation, if some home or company computer where you were > creating the binary distribution of PLplot had been silently > compromised so that our binary distribution of PLplot propagated an > attack vector (virus or whatever) to all our Windows users? > > Despite the above successful attacks on Linux-related sites, Linux > still has a better reputation for security than Windows so probably if > we wanted to do a binary distribution, it would be best to generate it > on a Linux/Wine platform where Wine was built on Linux from source and > only minimal components of the build platform (essentially just MinGW > and MSYS) were downloaded binaries. That implies everything else (such > as CMake itself, Python, etc.) would need to be built from source, but > that is certainly doable with the build_projects approach. > > > So my conclusion is that build_projects could be the core of something > much bigger, a Windows binary distribution of PLplot and all its > dependencies (or thinking really big here, a full blown binary > distribution of most free software). However, such binary > distributions are not completely straightforward (security is the > biggest issue in my opinion) so for now I think it is _much_ simpler > to distribute build_projects and let users build a complete binary > version of PLplot for themselves from that following a very simple > cookbook. For example, I am thinking a 10-minute build of a minimal > PLplot using build_projects might satisfy Clive's current needs. > > By the way, build_projects is getting close to being ready for someone > like Clive to do a minimal PLplot build, but there are still some > issues. For example, I still need to write some really simple > documentation that some guy like Clive can just follow. Also, there > are some generator issues I am currently investigating. For example, > the "Ninja" generator looks extremely promising, but I had to abandon > it for now (except for occasional specific diagnostic use) because it > doesn't (currently) support Fortran. I have discovered that the "NMake > Makefiles JOM" generator builds pure C projects like shapelib and > ndiff without issues, but I have yet to investigate whether that > generator can build a minimal PLplot that includes, e.g., C++, > Fortran, and Ada. And I am currently investigating a build-system bug > that showed up for "MinGW Makefiles" as a result of a recent change I > did. > > But "MSYS Makefiles" on Wine and "Unix Makefiles" on Linux are > currently working for a minimal PLplot build, and I am pretty sure the > issues I mentioned above for that build will be sorted out within the > next several days. But if Clive or other Windows users have more > complex PLplot needs including Qt4, pango/cairo, and wxwidgets, then > it may be a month or so before build_projects is ready for such needs. > > 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); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); 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 > __________________________ > > ---------------------------------------------------------------------------- > -- This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Plplot-devel mailing list > Plplot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/plplot-devel ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
