On 2006-11-18 10:16-0800 Brandon J. Van Every wrote:
I would like to know in the case of PLplot, how mature the Unix / Cygwin / MinGW / MSVC builds already were. Did they all essentially work already?
Under autotools, Linux and Mac OS X were fine, other Unices were untested. Cygwin and MinGW/MSYS worked reasonably well (I believe everything worked but dynamically loaded plug-in devices), but that took a dedicated effort (for example, a patch to libtool that was accepted by that team to correct bugs in shared library support for MinGW/MSYS a year or so ago). Our bare windows (i.e, windows without Cygwin or MinGW/MSYS) build was done with a completely different home-brew build system which provided a PLplot that was far from full featured. (I think just the core static library + examples, but Arjen may correct me.)
Were they all well supported and tested? Were the app internals essentially similar for all platforms, handling pathname conventions gracefully and so forth?
No and no. PLplot was far from perfect on windows. Arjen and one other windows developer have had to work to get shared libraries to work on windows with CMake since the home-brew windows build system only dealt with the static case. But they persevered (with some extremely useful help from this list on export and import DLL questions). Our windows platform is still not completely full-featured, but it has many more features (plotting devices, language front-ends, etc.) than it did before on windows which is why we are making a development release a week from today. We will follow that with other development releases with the eventual goal of completing the PLplot feature set (e.g., finally getting the plug-in version of our plotting devices to dynamically load) on windows. BTW, all the PLplot developers are volunteers who work on the package in their spare time and there are difficulties with the availability of open-source libraries on windows which I have alluded to before. For example, libltdl is missing so we are going to "CMakeify" the libltdl build (following advice given previously on this list from the KDE developers) to allow us to dynamically load the plug-in version of our devices. This is why it will probably take at least several more months to complete our feature set on windows. I guess the real reason the CMake has worked out so well on PLplot is we have a mix of developers who are extremely encouraging and tolerant about each other's (Linux or Mac OS X or windows) platform needs. I don't think our attitude is particularly unique in the free software world. For example, I presume this attitude is also the norm for the KDE project. In our own case, I belong to a very small minority of developers in the world who have never had any windows experience (moved to Unix in the 80's, and Linux in the 90's with no MS detours), but I was fully aware of our windows developer's long-term difficulties with improving our home-brew windows build system. Thus, one of my motivations for giving CMake a try in July was it had potential to solve the windows build limitations that existed back then. The rest is history; our windows developers have taken great advantage of that opportunity as I have cheered them on from the sidelines. 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 Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
