On 2014-02-11 17:54, Ben Boeckel wrote:
On Tue, Feb 11, 2014 at 17:18:22 -0500, Matthew Woehlke wrote:
On a loosely related note, did you know that there are now at least
two Python parsers for CMake script? (Besides I believe a C++ one in
KDevelop...)
1. https://github.com/ijt/cmakelists_parsing
2.
https://github.com/mwoehlke-kitware/Slicer/blob/3269-publish-extension-wizard/Utilities/Scripts/SlicerWizard/CMakeParser.py
It would be interesting to know how accurate these are. (Although if
the README for the (1) is accurate, that one isn't anything to write
home about.)
(One reason I mention it is because when I wrote (2), I made an
attempt to look at CMake's own parsing code. Alas, I do not speak
lex...)
Parsing in CMake is split into separate sections: the part which parses
the lines into CMake's command calls and the part which expands
variables (which is why "${cmd}(${args})" isn't allowed).
Right; I'd figured that much out on my own, and my own parser AFAICT
operates in a similar manner to CMake itself... it doesn't try to
tokenize variable substitutions (I didn't need that, and it would have
made the API non-trivially more complex), although it does choke if it
seems things like '${foo\n'. From what I can tell, the CMake command
parsing pass does also?
ExpandVariablesInString is the part which takes a string which may have
variables in it and dereferences them.
Yes, that's why your changes are probably not all that helpful to
understanding CMake's parsing... one must first understand the initial
parse pass, which I assume is still in lex (unless you rewrote it too
and forgot to mention it ;-), which I doubt).
If you're looking for corner-cases, check out the RunCMake.Syntax test
in the source tree. If you can handle that, you're probably doing pretty
well on the basics.
Thanks; I may do that some time.
Corner cases I hit while developing the new parser:
- in "\@var@", 'var' is expanded;
Is '@var@' actually expanded in plain CMake script? (OMG... it is...)
I wonder how many people are even aware of this. At any rate, at least
kate doesn't highlight it. (vim doesn't either, but vim also doesn't
highlight '${var}', so no surprise it doesn't.)
Alas, my parser does not accept these at present.
- '\;' is always literal (don't ask why, but if you don't keep the
slash around, things fail);
Oh, ick... right now I'm not handling ';' as special but as literal text
of an argument. If anyone is using that instead of whitespace as an
argument specifier, then too bad :-). (For now at least, since fixing it
will require some odd fiddling with the API. Or possibly declaring that
';' now counts as whitespace :P.)
AFAICT, \; is only an escape when it *isn't* quoted. In quotes it's just
two normal characters. (This appears to be the only escape that behaves
differently quoted versus not.)
- don't forget "$CACHE{}".
Ah... heh, I don't handle that :-). (Trivial change, though.)
Helpful info; thanks!
--
Matthew
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
