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 __________________________ _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake