QMake status and other ideas for our students

[Andreas Pakulat]

On 05.01.11 16:18:40, Milian Wolff wrote:
> Hey all,
> 
> this email is mainly aimed at the french students hacking on KDevelop. Their 
> team size has increased and now counts 10 people, awesome. I hope we continue 
> to see more good work from you guys.
> 
> Here is an outline of the current status of the QMake plugin, in case you are 
> interested to work on it:
> 
> First up, you can find it here:
> https://projects.kde.org/projects/extragear/kdevelop/experimental/kdev-qmake
> 
> You'll need kdevelop-pg-qt to build it:
> https://projects.kde.org/projects/extragear/kdevelop/utilities/kdevelop-pq-qt
> 
> Now, lets look at the plugin. It utilizes the AbstractProjectManagerPlugin 
> (shared between generic manager, custom buildsystem and QMake). There are some 
> bugs in there, for example renaming a file doesn't seem to delete the renamed 
> file sometimes it seems. Besides that, most actions from the Project Manager 
> View should work fine.
> 
> The real work needed to be done right now is the QMake support though. First 
> up, we need a dialog similar to what CMake shows, when importing a project. It 
> should ask for the build dir (for shadow builds), have a lineedit to insert 
> custom stuff, defaulting to CONFIG+=debug. Then this setting, esp. the path to 
> the build dir, needs to be handled in the plugin to make sure qmake is run 
> from there and the qmakecache files are found properly. I think this is the 
> most important missing part of the qmake support plugin.

As the original author of the qmake plugin for KDev4 let me throw in my 2
cents regarding it:

The idea to support custom functions and easy parsing of all those mkspecs
was that the plugin only implements the basic functionality that qmake
itself has in qmake/*.cpp. There  are some string-handling and
list-handling functions there, resolving variables and thats about it IIRC.
The rest of qmake's logic, in particular all the platform-specific stuff
like compiler, default-defines and includes are all set up through the
mkspecs. Luckily these have the same format as normal qmake files, hence
can be parsed in the same way. So the idea was to simply parse and evaluate
them, keeping a list of functions being defined and allow for code to call
these functions, much like qmake itself does. The difference is that all
that the qmake-plugin in kdevelop is interested in are variables and how
they're changed by functions to get the actual build-time values for things
like source-files, includes, defines etc.

Andreas

-- 
You'll be called to a post requiring ability in handling groups of people.