Third iteration of QMake parser, looking for a parser generator

Andreas Pakulat apaku at
Tue Jul 3 10:52:39 UTC 2007

On 03.07.07 11:16:04, Roberto Raggi wrote:
> Hi!
> 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:
> >
> >kdev-pg/flex:
> >  + 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 ( 
> ? :-)

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
problem either.

> 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
qmake language.


You never hesitate to tackle the most difficult problems.

More information about the KDevelop-devel mailing list