Third iteration of QMake parser, looking for a parser generator
apaku at gmx.de
Tue Jul 3 10:52:39 UTC 2007
On 03.07.07 11:16:04, Roberto Raggi wrote:
> Il giorno 03/lug/07, alle ore 10:35, Andreas Pakulat ha scritto:
> >If you look at what local time it was when I wrote it you know why I
> >left it out :) (Simply forgot). So here it is:
> > + A dependecy that is introduced anyway when one of the language
> > plugins returns into kdevelop, good C++ code for the parser,
> > ok interfacing with a flex-generated C++ class
> > - Need to write an AST-visitor to produce a usable AST as semantic
> > actions are completely lacking in this one.
> ... and what's wrong with QLALR (http://labs.trolltech.com/blogs/category/labs/compilers/qlalr/)
> ? :-)
Its not documented. Not at all. And no the .g file in it and the
resulting code is no documentation that I can work with. Sorry, I really
looked into it and hoped it could be used, but thats not possible.
> I have to say that I'm not very familiar with cmake,
Its about qmake, not cmake ;)
> so I don't know if it is better to use a LL-generator(e.g. kdev-pg) or
> LALR-generator(e.g. QLALR). It also depends from the runtime needed by
> the generated parser. For instance, KDevelop owns the kdev-pg runtime
> and that is really cool because *you* have a lot of control (== you
> can be sure that kdev-pg will include your fixes). QLALR is also
> cool, but it has no runtime. That means you have to write the parser's
> driver, the AST and so on.. but that's the cool thing about QLALR.
I already have an AST that is usable and a driver is not really a
> About flex. I really think you should use something else, maybe your own hand written scanner.
Hand-written scanner: No, I don't have time for that, especially for
You never hesitate to tackle the most difficult problems.
More information about the KDevelop-devel