[CMake] Re: CMake and Lua

[Brandon Van Every]

On Sat, Mar 1, 2008 at 1:44 PM, Enrico Scholz
<enrico.scholz at informatik.tu-chemnitz.de> wrote:
> Bill Hoffman <bill.hoffman at kitware.com>
>  writes:
>
>
>  >> I find that the CMake script language seems designed to make COBOL
>  >> coders feel they don't actually have the worst job in the world.
>  >>
>  > So what exactly about the CMake language gives you this feel?
>
>  * the mix of case-sensitive and case-insensitve language elements
>
>   Afair, HTML in 1992 was the last (non-educational) language with
>   case-insensitive keywords ;)

I'm happy that commands don't need to be ALL_CAPS anymore.  It saves
typing and looks better.  I don't mind too much that KEYWORDS and
RESERVED_VARIABLES are still ALL_CAPS.  Having SYSTEM_CONSTANTS be all
caps is pretty common in other languages, and that's how the
RESERVED_VARIABLES are being used for the most part.  I guess that
just leaves KEYWORDS.  I see below that you take issue with those,
caps or not.

>
>
>  * no well defined syntax:
>
>   - missing datatypes; all seems to be a string.  Mastering ';' and
>     spaces is trial-and-error game :(

Totally agree on this point.  It needs documentation.  My suggestion
on the matter is http://cmake.org/Bug/view.php?id=6295 "Document core
syntax in a chapter format."  Feel free to add your comments there.
Perhaps if enough people comment on it, it'll happen.  I'd like to
think that comprehensive documentation would alleviate the problem.  I
think people could still regard it as warty and type unsafe, no matter
how much it is documented.  I would indeed like to have a type safe
list operator.  It's easy to use lists in CMake if you know what
you're doing and you're not pushing things too hard; I think that's
likeable despite the liabilities.

>     parameters
>     are not delimited e.g. by ',' but start with a keyword understood by
>     actual macro only.

Is that necessarily bad?  If you delimit with commas instead of
keyword tags, then you can mess up the order of the arguments because
you don't remember what order the comma arguments are supposed to be
in.  Some languages have "named arguments," is that the right
technical term?  Anyways I don't think that keywords are particularly
difficult to use in practice.  I've probably typed string(REGEX
REPLACE ..) more than any human should though.

>
>   - function/macro calls are ambiguous; everything is a string,
>
>     E.g. why will
>
>     | EXEC_PROGRAM(foo ARGS ARGS foo)
>     | EXEC_PROGRAM(bar HERE ARGS bar)
>     | EXEC_PROGRAM(baz ARGS HERE baz)
>
>     execute
>
>     | running foo foo  2>&1
>     | running cd "HERE" && bar bar  2>&1
>     | running baz HERE baz  2>&1
>
>     ?

Hm.  I haven't run into this kind of corner case in my own work, but
that does indeed look troublesome.  Perhaps you should file a bug
report on it.  I've filed reports for things like, why not have TRUE
and FALSE be actual constants.

>  * inconsistent behavior across the subsystems (build, install, test);
>   e.g.
>
>   | ADD_CUSTOM_TARGET(test COMMAND echo "A=\${A}")
>   | INSTALL(CODE "MESSAGE(\"A=\${A}\")")
>
>   | $ make A=a test
>   | A=a
>   | $ make A=a install
>   | A=

There are definitely string argument evaluation level bugs.  I
resorted to passing variables rather than strings, so that the strings
can't be mangled.  It's definitely uncool, and one learns it from the
school of hard knocks.  Again though I think filing bugs about these
things can be helpful.  If enough people file the bugs, then the
pattern will become clear, and I imagine things will be addressed.
Either by fixing them or migrating to Lua.


Cheers,
Brandon Van Every