[cmake-developers] Branches on next
Matthew Woehlke
mw_triad at users.sourceforge.net
Tue Feb 11 19:16:49 EST 2014
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
More information about the cmake-developers
mailing list