[CMake-Promote] Re: Language barrier

[E. Wing]

> And BTW, you should also be doing basic research on what's out there in
> Lua build-land.  For instance, the Lua front-end for SCons.
> http://luaforge.net/projects/hamster/  Let's hear what it can do that
> CMake can't, and vice versa.  And anything else you scare up with
> Google; that was just my 1st obvious hit.  If you want more grist for
> the mill of "build tools that do various things, some of them possibly
> having languages," here's a whole page of 'em:
> http://www.scons.org/cgi-bin/wiki/SconsVsOtherBuildTools

Yes, I am aware of Hamster. I have chatted with the author on several
occasions, usually on SDL related topics. Asko seems to be a pretty
nice guy and has a list of various projects he works on. Hamster is
just one of them. It seemed to be mostly a one man effort. Considering
Asko works on other things, I suspect it wasn't hard for him to build
the front-end for SCons which might imply great deal about how SCons 
was architected. Hamster is not intended as a competitor to SCons. It
is a front-end to SCons so you can use Lua instead of Python.
Comparing CMake to Hamster wouldn't really say anything more or less
than comparing CMake to regular SCons. This is just how people within
the SCons community are dealing with the "language barrier".

As for the webpage with the list of build tools. This is nothing new.
But in practice from what I see, typically the final decision is
between SCons and CMake because of their advanced native project
generation capabilities which most of the others lag in. But then the
CMake language thing gets in the way and people choose SCons.
(However, CMake is noticeably absent from the list. You might want to
write up a description of CMake and get it added to the list.)


As for why CMake needs a "real" language. Take this stupid example:

TRY_COMPILE(MY_RESULT ...)
IF(${MY_RESULT} MATCHES "Unknown symbol _foo")
 # Do stuff to add libraries that contain _foo
 ...
ENDIF(${MY_RESULT} MATCHES "Unknown symbol _foo")


When TRY_COMPILE fails, this code works fine. But when TRY_COMPILE
passes, CMake barfs on the line because of a syntax error and aborts
the generation process. This is apparently because ${MY_OUTPUT}
expands to nothing and you have an invalid IF statement.


This is really stupid in my opinion and a "real" language wouldn't
have these kinds of ambiguities. Generally, ${MY_OUTPUT}  would be
treated like nil and the IF clause would just be false and runtime can
just keep going. But CMake throws a runtime error here.

(Actually, this wasn't the full story because in some cases, there was
stuff in MY_OUTPUT and it continued to fail. Something else turned out
to be horribly wrong, and I was told that I needed to rewrite my
approach to calling TRY_COMPILE which had some different ambiguity
problem with strings that escaping and quotes couldn't handle.)

The CMake language has given me numerous problems with strings and
lists, most of which are too complicated and involved to post here. I
blame most of these problems on the language which may or may not be
fair, but I know for a fact that I don't have these kinds of problems
in Lua or Perl. Because of my past problems, I absolutely dread coding
complex things in the CMake language. I can handle the simple, direct
API calls, but complicated things (which I have to do once in awhile)
frustrate me to no end.

I'm not a language expert so I don't really know why these things keep
breaking for me, but based on Brad's post, I suspect he knows why and
has better examples and I'm hoping he'll chime in here.


So really, with Hamster and the other projects you pointed too,
nothing has changed. Ultimately, it's still SCons vs CMake and the
language barrier is CMake's biggest problem in my opinion.

If anything, you should be even more worried about SCons because their
community is already addressing the language barrier issue with
projects like Hamster. And if Parrot ever finishes and works like the
hypothetical #3 I posted, you should be even more worried because the
language barrier problem ends there for them, whereas for CMake the
value of the language barrier issue is still in question.

Thanks,
Eric