[CMake] Suggestion for CMake platform/compiler detection

[Brandon J. Van Every]

Alan W. Irwin wrote:
> Our windows platform is
> still not completely full-featured, but it has many more features 
> (plotting
> devices, language front-ends, etc.) than it did before on windows 
> which is
> why we are making a development release a week from today. 


It sounds like Chicken and PLplot were at comparable levels of Windows 
support when they each started switching to CMake.  Unix-oriented, hand 
crafted builds exist for Windows, they sorta work but tend to break, not 
all features available on the Windows side.

>
> it will probably take at least several more months to complete our 
> feature
> set on windows.


I'm guessing your initial snowball is a function of project size.  More 
developers, so if more people get "turned on" to CMake, they can do 
more.  Smaller projects only end up with 1 guy doing most of the work.  
This is also true of larger projects when political buy-in is absent.

Anyways, I hope you can maintain momentum with CMake and Windows as you 
*finish* the cross-platform unification.  I've done it; I have the 
perspective of having done it.  I wonder if projects like yours will 
tend to chug through to the end, or whether they'll encounter late-term 
frustrations that slow or halt the progress.  A lot of this is 
application dependent; if there had been much more to fix in Chicken, I 
may have given up. 

Political difficulties also ensue in the end game.  At that point, 
development shouldn't be driven by Autoconf anymore.  But, the Autoconf 
guys are used to their standard drill, and they persist.  Similarly, the 
Linux guys are used to their Linux drill and not the newfangled Windows 
stuff.  In the worst case, the "old guard" drives the old system 
forwards with lots of new features, making more bugs for CMake and / or 
Windows than you can fix.  At that point, one puts one's foot down and 
says, "Are you moving on with the new CMake build or not?"  It worked 
out ok in Chicken's case, but for a time I was worried that the work 
could end up being all for nothing. 


>
> I guess the real reason the CMake has worked out so well on PLplot is we
> have a mix of developers who are extremely encouraging and tolerant about
> each other's (Linux or Mac OS X or windows) platform needs.  I don't 
> think
> our attitude is particularly unique in the free software world.  For
> example, I presume this attitude is also the norm for the KDE project. In
> our own case, I belong to a very small minority of developers in the 
> world
> who have never had any windows experience (moved to Unix in the 80's, and
> Linux in the 90's with no MS detours), but I was fully aware of our 
> windows
> developer's long-term difficulties with improving our home-brew windows
> build system. Thus, one of my motivations for giving CMake a try in 
> July was
> it had potential to solve the windows build limitations that existed back
> then. The rest is history; our windows developers have taken great 
> advantage
> of that opportunity as I have cheered them on from the sidelines.


Helps also to have multiple motivated Windows developers.  In Chicken's 
case I was the only one.  John Cowan came along later, but he guns on 
Cygwin, and I don't feel that exactly counts.  Porting to native Windows 
means getting things to work on MSVC and MinGW.  That said, his Cygwin 
testing definitely improved the CMake build, so the Cygwin aficionados 
are definitely useful to the overall enterprise.  Also, he was useful 
for advocating *CMake*, whether or not he cared about native Windows 
stuff.  The two problems, Autoconf --> CMake and Unix --> Windows are 
entwined in each other, but they are also distinct.


Cheers,
Brandon Van Every