Third iteration of QMake parser, looking for a parser generator

Roberto Raggi roberto.raggi at
Fri Jul 6 10:28:34 UTC 2007

Il giorno 05/lug/07, alle ore 19:05, Amilcar do Carmo Lucas ha scritto:

> How about adding all this nice info to the wiki ?
> (inclusive files)

That's a very good idea. I really think that programming language  
plug-ins and build tool plug-ins have a lot in common. If you think  
about it both plug-ins have to recognize a language, build a  
representation for it and do some incremental update + provides some  
code refactoring tools. What is my proposal? Let's say you want to  
add qmake support to KDevelop. Well,

  - first you need to implement a programming language plug-in for  
qmake. The front-end should be incremental because you want to change  
it using the built-in text editor.

  - you build a "project model" (something like the code model in  
kdev3) using an AST->ProjectModel converter. The project model needs  
to have "pointers" to the "code model", so if you have a project  
model item (e.g. the item for file.cpp) you should be able to get the  
"code model" of that item.

  - then you implement some code refactoring tool. For example, add a  
file to the project, or rename a file, ...

  - ...and if you have time you write a GUI editor for the project

so, language plug-in or project plug-in!? what's the difference? well  
it is simple, a language plug-in knows how to create code model items  
and a project plug-in knows how to create "root items". If you think  
about it we had something like that in KDevelop3. The code model in  
kdev3 is a collection of FileModelItem it is flat (no FolderModelItem  
or SubProjectModelItem) because KDevProject in kdev3 *is* flat (it  
returns a QStringList of file names :-). The weird thing is that in  
kdev3 we build the root of the "code model" (the filedom items) in  
the programming language plug-in and not in the project plug-in! :-)  
hehehe well, nothing is perfect ;-) This introduced so many problems,  
for instance the C++ plug-in doesn't know the file dependencies so it  
parse all the .h files and then the .cpp files just to try to get a  
decent code model. See? you don't have this kind of problems if you  
build the FileDomItem in the project plug-in and then you use the  
language plug-in to populate it.

ciao robe

More information about the KDevelop-devel mailing list