[cmake-developers] Branches on next

[Matthew Woehlke]

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