Third iteration of QMake parser, looking for a parser generator
roberto.raggi at gmail.com
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.
More information about the KDevelop-devel