[CMake] Suggestion for CMake platform/compiler detection
Brandon J. Van Every
bvanevery at gmail.com
Sat Nov 18 01:51:22 EST 2006
Alan W. Irwin wrote:
> [The Autotools] 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.
Yes, the Autotools have many liabilities. Most notably, they are built
in layers, all with different design requirements and beholden to
different legacy issues. It makes some things impossible to accomplish;
one simply has to accept the known workarounds. The Autotools docs are
evolved enough, that the workarounds are actually in the docs....
>
> 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,
Getting started with CMake is easy. It lulls people into a false sense
of security about the amount of work involved... which from a CMake
promotion standpoint, is a good thing. I'm cynical about what it takes
to *finish* such jobs. In the absence of money, I wouldn't undertake it
again.
> and the whole project quickly snowballed with all
> our active developers soon starting to contribute to our CMake build
> system.
Your dynamics are different because you got a snowball effect. What if
you hadn't? What if you had been the only guy stuck with working on the
build? There aren't enough developers working on the Chicken Scheme
build to get any kind of snowball effect. Basically there's myself,
Felix, and occasional patches from people who notice things that are
wrong. I didn't get any snowball, I just trundled away for a long
time. What I did get, however, was the buy-in of the principal author.
So that with sufficient elbow grease, I could ensure that CMake would be
the future and not Autoconf. So yes there's a future in CMake
migrations, *if* you have the manpower to make the transitions.
I'd like to get automated Dashboard testing going for Chicken, but I
don't want to lead it the way I led the build. Every time I bring this
sort of thing up, crickets chirp. And, I'm quite sure there's a quorum
of Chicken developers who actually care about automated testing. But
nobody wants to do the work.
I wonder if this is all simply a function of project size, longevity,
and the social relationships that are bred / culled from projects that
survive a long time.
> 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.... :-)
I would have never undertaken the Chicken Scheme build without Felix's
buy-in as a prerequisite. It sounds like you had some authority to make
things happen in the PLplot project. Or at least, your findings would
likely be taken seriously by a core group of programmers who knew your
work. Not everyone is in that position.
Not everyone coughs up the initial labor either. It would be useful to
track the status of CMake-ifying projects, to see who thrives and who
dies out.
For the record, I crossed the finish line, then the proverbial medics
carried me away on a stretcher. I'm strictly in maintenance mode; I
don't plan to cough out new CMake code anytime soon. But, the
groundwork I laid is thorough, so it's doing its job and getting
extended. I just can't lay out that kind of labor anymore, not when it
threatens the roof over my head. If I could magically track stuff, I'd
love to track the monetization of CMake. Without $$$$$ life is hard. I
see that as the main pitfall of open source. A lot of the projects
don't make any $$$$$ for the people working on them, and a lot of the
commercial marketplace doesn't respect tools with no $$$$$ attached to them.
Cheers,
Brandon Van Every
More information about the CMake
mailing list