[CMake] Suggestion for CMake platform/compiler detection

[Brandon J. Van Every]

Brandon J. Van Every wrote:
> Alan W. Irwin wrote:
>
>>
>>
>> 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. 


Some private discussion with Bill has made me realize I'm not providing 
enough context for what exactly is hard.  Many of the problems of GNU 
Autoconf build migration are not CMake's fault.  They will happen 
anytime one moves from a Unix-centric build culture to a truly 
cross-platform Unix / Cygwin / MinGW / MSVC build culture.  Because 
Autoconf doesn't handle MSVC, builds typically have a completely 
different build system for MSVC.  This often means the internals of the 
application have diverged, as was in the case of Chicken.  Different 
pathnames, different shell assumptions, different quoting problems, 
etc.  Getting an app to be truly cross-platform is a lot of gruntwork.  
This is why I'm askance about some of the suggestions, like name 
canonization, being a big improvement to CMake's future.  Yes they'll 
help, any good incremental design will help, but strategically it's just 
not the core problem one faces when unifying a build.

The reason some Unix guys won't budge, has nothing to do with whether 
CMake is a better tool than Autoconf.  It's because going truly 
cross-platform to Unix / Cygwin / MinGW / MSVC has no value to them, and 
represents tons of gruntwork.

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?  Were they all well supported and tested?  Were the app 
internals essentially similar for all platforms, handling pathname 
conventions gracefully and so forth?  If all these things are true, then 
that's a great app to CMakeify.  If I could cherry pick what apps to go 
after and convert, that's the sort of app I'd go for, because CMake 
would ride the coattails of a bunch of build work that's already been done.


Cheers,
Brandon Van Every