[CMake-Promote] Re: Language barrier

[Brandon J. Van Every]

E. Wing wrote:

>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.
>
>
>The CMake language has given me numerous problems with strings and
>lists, most of which are too complicated and involved to post here.
>
It would be helpful if you filed these as bugs at 
http://www.cmake.org/Bug .  Hopefullly reproducible bugs.  It would also 
help if you made a list of the extant bugs that are "language 
deficiencies," whether filed by you or by others.  Are we talking about 
piles of bugs and intractable architectural problems, or are we talking 
about, say, 8 bugs that need squashing?  Clearly there's some 
undesireable behavior; the question is, is implementing a "real 
language" a necessary or cost-effective way to fix the behavior?

>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.
>  
>
Perhaps you and Brad could work together on this assessment.


Cheers,
Brandon Van Every
"We live in a world of very bright people building
crappy software with total shit for tools and process."
                                - Ed McKenzie