[CMake] Suggestion for CMake platform/compiler detection

[Alan W. Irwin]

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
__________________________