[CMake] Suggestion for CMake platform/compiler detection

[Brandon J. Van Every]

Length warning!  As a preamble, I want to make it clear that I'm not a 
proponent of Stop Energy.
http://www.userland.com/whatIsStopEnergy
I throw cold water at people, then tell them to knock themselves out 
with whatever they feel needs doing.


Tanguy Krotoff wrote:
> Brandon J. Van Every wrote:
>> People who feel neutral about Autoconf, or who are in fact pleased 
>> with it, aren't going to up and do anything for Windows anytime 
>> soon.  For those people, it will take a *long* time for migrations to 
>> happen via CMake.
>
> I do not agree, yes it will take time but if you provide a much better 
> tool that the existant one (+ in some extend is compatible with the 
> old one), developers will switch.


CMake is not compatible with GNU Autoconf.  It merely achieves similar 
functionality with a cleaner architecture on more compilers.  So the 
cost of switching a 75K LOC project like Chicken Scheme can easily be 1 
man year.  Granted, we had a quick and dirty version within days, and 
that's a powerful selling point.  But to actually duplicate the full 
functionality of the Autoconf build, while maintaining the stability of 
the old build, took 1 year.  That's because builds for non-trivial 
projects have layers and layers and layers of STUFF that people don't 
think about when it's all working.  Also because it's one thing to do a 
CMake only build, and another thing to do a GNU Automake only build, and 
a quite different beast to have the two play well together.  I did it; 
it was a PITA.  And I'd hate to think how it would have gone if the 
political landscape had been different.  When making an architectural 
decision I only had to convince Felix, the principal author, and his 
coding aesthetic sense is similar to my own.  What if I had had to 
convince a committee?

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.


>
> We can reduce migration time by simply providing a very nice and 
> simple API for building software using CMake, and the first step 

Frankly, lots of steps have been taken already.  You're talking about 
cleaning up warts, not "first steps."  If you're deeply interested in 
conquering the world with CMake, why not join the cmake-promote mailing 
list?  Technical fixes aren't the only things that CMake needs.  
Although, in practice, they've been the easiest for me to provide (in 
the form of bug reports), for the energy I've been willing to expend.


> is to fix little things like:
>
> if (GCC) and not if (CMAKE_COMPILER_IS_GNUCXX)
> if (ICC) and not if (CMAKE_C_COMPILER MATCHES "icc")
>
> an API should be *consistent*, if you choose to have
> if (MSVC)
> if (MINGW)
> then you should have if (GCC), if (ICC)...


I agree that these are inconsistent / not so good / not so desireable.  
Feel free to file a feature request, or even to implement them if you're 
facile with the sources.  I'm not, so I make feature requests.  Or if 
something is not really a feature, but rather documentation that is 
rightly considered missing, I file a "content" bug.  I find that these 
sorts of low priority items do tend to get dealt with 1..2 months after 
I file them.  That is to say, filing coherent feature requests / 
documentation bugs does count as action on your part.

>
> And saying "there's coverage, it's just ad hoc, not canonized, and has 
> an inconsistent interface.  At present this doesn't trouble me, 
> personally" won't help

Right.  Goading *YOU* into filing the feature requests you are 
discussing *WILL* help.  ;-)  I already went up this learning curve, 
these issues aren't cramping my style.  Documentation issues were 
cramping my style in a big way, so I filed some documentation bugs a few 
months ago.  I didn't get everything I wanted, but the docs do have URL 
pointers to the online wiki now, and that's a significant step forwards 
for newbies fumbling around.  In the constellation of all my present 
programming priorities, I'm currently at peace.  Your itch; so go 
scratch it.


> CMake users don't care about CMake, they only care about building 
> their software and they don't want to google/read the doc because if 
> (MSVC) works and if (GCC) or if (ICC) don't as they expected.

Actually they do want to read the docs, and that's why I filed content 
bugs about it, because in a number of instances it was rather difficult 
to find what they needed to know, even if they were making concerted 
attempts to RTFM.  Here's how I see the priorities:

1) API works
2) documentation is findable
3) documentation is complete and clear
4) API is consistent


>
> A more important issue, you can write:
> add_definitions(${DEF})
> include_directories(${INC})
>
> but you cannot write:
> add_compile_flags(${FLAGS})
> add_link_flags(${FLAGS})
> !!!!
>
> No this would be too simple... so you have to check the doc, google 
> and finally find out that it works in a totally different way!
> set_target_properties(${PROJECT_NAME} PROPERTIES COMPILE_FLAGS ${FLAGS})


But, this drill has never been a stumbling block for me personally.  If 
there's a way to do it, and it's documented, I can read how to do it.  I 
don't expect to automagically intuit how to do stuff on the basis of API 
consistency principles.  I expect to RTFM, quite a number of times, 
until I know what to do.  Consistency of API just makes it more 
palatable and enjoyable.  It doesn't obviate RTFM.

Most of CMake works like SET_TARGET_PROPERTIES, with verbose tags for 
the next field of input.  The API may not be 100% consistent in this 
regard, but it is probably 85% consistent.

I did get starter code for the Chicken Scheme build once upon a time.  
Seeing code that actually works, definitely helps.  That's part of why 
I've tutorialized the Chicken Scheme build, so that newbies can see what 
they actually need to do.  You can certainly take the tack of perfecting 
the APIs, but another equally valid approach, is to provide good 
tutorials and repositories of sample code.  I don't really want to learn 
anything, I just want to look at how things are done and copy them.  
CMake may not be a perfectly refined API, but typically it works, and 
it's a helluva lot better than the GNU Automake stuff!

Actually one way that Automake is "better" than CMake, is it has much 
more complete documentation, with examples, caveats, pitfalls, concerns, 
etc.  This is all in their standard shipping documention.  Of course, 
they're documenting a build system spread out across Automake, Autoconf, 
Make, and Libtool, so the end results are horrid and there's plenty of 
hunt and peck.  But it's a *darn well documented* horrid mess.

>
>
> Your answer will probably be "not happy? send a patch!"
>
> and here is my patch:
> http://dev.openwengo.org/trac/openwengo/trac.cgi/wiki/OWBuild
> http://dev.openwengo.org/trac/openwengo/trac.cgi/browser/wengophone-ng/trunk/cmake/Modules/owbuild 
>
>

This isn't a patch though.  This is a derivative work; you're running 
off in your own direction.  Do you have a patch for the 
ADD_COMPILE_FLAGS, ADD_LINK_FLAGS inconsistency you describe above?  
Minor adjustments like that would be worthwhile.


> This permits me to create build scripts for cURL, PortAudio, 
> libGaim... in 1h, check how simple they are !
> Even somebody who never heard about CMake can understand them...

I applaud the effort and skill you have put into this!  But...

...there's the important issue of whether people who *HAVE* heard of 
CMake can understand them.  If you macrotize all the CMake code out of 
existence, then people have to dig through your code and documentation 
to understand what's going on.  If people need help with what's going 
on, they have to ask you, because nobody else in the CMake community 
knows what's going on.  This makes you a single point of failure for 
other people's projects; many people won't use stuff if there's only 1 
guy who "supports" it.  That of course can change over time if your code 
does in fact prove to be really really useful; you could conceivably 
build a higher level community around your offerings. But it takes years 
to establish such utility, and you have said yourself, you are hardly 
finished.

The worst code I wrote for the Chicken Scheme build was the heavily 
macrotized stuff.  A few passes later I ended up getting rid of it.  In 
the real world, with real people banging on your build who don't know 
what's going on, the dumb way is often the maintainable way.

>
> Since I have a very high level API, I can do very high level things 
> like choosing from the cache if I want a shared or a static library 
> (and don't tell me the problem is a simple -DMYPROJECT_EXPORTS), copy 
> automatically files on the fly, integrate an inheritance system...
>
> It's not fully finished yet, I have to write more doc + test deeply 
> the macros
>
> Now I'm scratching my head: do I extend my macros and add if 
> (OS_WINDOWS), if (OS_MACOSX), if (OS_LINUX), if (CC_MSVC), if 
> (CC_GCC)... or do I stick with if (APPLE), if 
> (CMAKE_COMPILER_IS_GNUCXX) and if (CMAKE_C_COMPILER MATCHES "icc")??


Are you a team player or a maverick?


>
>
> CMake is a wonderful tool, very glad people are developing it but 
> please create a simple, consistent and high-level API and then people 
> will switch

The crux of what I feel we're arguing about here, is what I see as your 
notion of "build it, and they will come."  The history of the software 
industry clearly demonstrates that perfectly clean APIs are not 
generally the winners in the API wars.  Adoption decisions are driven by 
other considerations, like:

- how many $$$$$$$$$ is locked up in this API?
- what is the maturity of this API?
- what is the stability of this API?
- what is the size of the support community for this API?
- what is the current popularity?
- does it work?
- does it do what WE want?
- can we make it do what we want?

I hope you're willing to work with the CMake developers to make 
improvements that a quorum of key people feel are desireable.  Note: I 
deliberately do not say "most people," as I don't believe in Stop Energy.

You don't need to spend time convincing people here about the merits of 
cleaner APIs.  The CMake developers value cleaner APIs, and it's a 
cleaner architecture than GNU Autoconf by far.  However, there are 
implementation considerations, as CMake is a *successfully* evolved 
project.  Some things are easy to do, some things are not.  Some things 
are easy but not desireable, because there are maturity / support issues 
to consider.  What you need to do, is plug your thoughts, reproducers, 
and patches into the bug tracker.  http://www.cmake.org/Bug  That's how 
things actually get done around here.  And, they do get done, if not 
instantly.


Cheers,
Brandon Van Every