[CMake] Suggestion for CMake platform/compiler detection

[Brandon J. Van Every]

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