[CMake] Suggestion for CMake platform/compiler detection

[Alan W. Irwin]

On 2006-11-17 16:56-0800 Brandon J. Van Every wrote:

> When projects are that expensive to re-architect, people don't just
"switch." They carefully consider their options only when they're in a lot
of pain.  So if a Linux-loving Autoconfer's build is working more or less
ok, they ain't fixin' what ain't broke.

Brandon, I largely agree with many of the things you said in the rest of
your post, but let me add my "Linux-loving Autoconfer" PLplot experience
which is different than your generalization above.  In short, we weren't in
a lot of pain from autotools, but we still made the switch to CMake because
we did have some concerns about autotools, the combined power of many
developers made the switch really easy, and we had two starting catalysts
(Alex's article and me).

Here are the details.  PLplot has a fairly complicated build consisting of a
few core libraries, several language interfaces to those libraries, a large
number of plotting device plug-ins, and an extensive docbook-based
documentation build.  To do all these build tasks, PLplot has used a nicely
organized autotooled build for some time which took several years to fully
develop.  However, although I was largely comfortable with autotools and was
probably the second-ranked autotools expert amongst our developers it
bothered me that three different syntaxes (especially m4 which I really
dislike for autoconf, but also automake and libtool syntax) were required,
that any extension of PLplot always seemed to involve quite a bit of
autotools work, and that the fundamental changes in autoconf, automake, and
libtool that kept occurring meant we had to keep changing our configuration
files in "magical" ways.  For example, earlier this year I tried a
preliminary version of libtool-2 to see whether that fixed some fortran
issues, and it took help by a guru on the libtool list (making what seemed
like an arbitrary reordering of our configuration) to get our build to work
with that newer version of libtool. That help was much appreciated, but
still the necessity for that help and the other factors I have mentioned
made me uneasy about continuing to depend on autotools.

Then, I read the article (http://lwn.net/Articles/188693/) by Alex on KDE's
switch from autotools to cmake.  That article really resonated with me
(especially the remarks about simple CMake syntax which every developer
would find it easy to understand) so I presented the possibility to the
PLplot development list of moving to a CMake build system.  However, I got
the "if it ain't broke, don't fix it" standard reaction that Brandon noted
above.  Fortunately, I ignored that reaction.

One of the advantages of trying out CMake for an autotoolized project is the
two build systems can coexist peacefully.  Also, as Brandon noted the CMake
syntax is really easy to learn so you can quickly show some results.  So all
it really takes to start the move to cmake is just for one catalyst
developer for a project to be convinced enough to make a start.

I was that catalyst guy for PLplot. I started in early July soon after
Alex's article came out. I soon had a proof-of-concept CMake build for one
of our simpler libraries, and the whole project quickly snowballed with all
our active developers soon starting to contribute to our CMake build system.
The result is that one week from now we plan to make a PLplot release
featuring the new CMake build system.  This new build system is already a
significant improvement on our old autotools-based and separate
windows-based build systems and is generating significant additional PLplot
developer activity because CMake is so easy to work with.  I think it is
fair to say this project succeeded beyond the wildest dreams I had in July
when I started it.

This example of how CMake has quite casually taken over one autotoolized
project reflects in my opinion the fact that we live in a chaotic world
where small positive actions often have large positive consequences.  So in
such a world careful planning, discussion, and paying attention to
nay-sayers (who automatically always claim you have not done your planning
carefully enough) can actually be counterproductive time wasting. Instead,
my advice is to take small positive actions ("show them the code") to see
what might happen whenever you have the opportunity to do so, and always try
to identify nay-sayers (those who seem to get a kick out of always being
negative) and ignore what they say.... :-)

In my case, that casual "try and see" tactic paid off big-time with a great
new build system for PLplot, and I think there are lots of others in the
free software world who are following a similarly casual path to CMake.  The
result is that CMake mindshare is rapidly increasing. Of course, great
articles like that written by Alex also have a large catalytic effect.

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
__________________________