On Sat, Mar 1, 2008 at 1:44 PM, Enrico Scholz <[EMAIL PROTECTED]> wrote: > Bill Hoffman <[EMAIL PROTECTED]> > 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 _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake