On 2014-02-11 14:49, Ben Boeckel wrote:
I've just pushed two branches into next:

     dev/custom-parsers
         Replaces the parsers in cmMakefile::ExpandVariablesInString with
         custom code rather than lex/yacc. The parsers in
         cmGeneratorExpression::StripEmptyListElements
         cmSystemTools::ExpandListArguments and have been optimized to
         not do char-by-char result building and
         cmGeneratorExpressionLexer::Tokenize now uses a switch
         statement. These gain about 20% in the configure step (generate
         is largely unchanged; maybe 33% for Makefiles (though Makefiles
         generate faster than the configure for ParaView) and minimal for
         Ninja).

     dev/fix-sublime-compile-flags
         Fixes a typo in the sublime generator (found while working on
         another branch).

Please test the custom-parsers branch. The tests pass, but if there are
any corner cases there, new tests should be included. Testing on
non-Linux would be nice as well.

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...)

--
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

Reply via email to