Questions about QMake plugin

Andreas Pakulat apaku at
Wed Feb 23 21:56:23 UTC 2011

On 23.02.11 20:52:41, Julien Desgats wrote:
> Hey all,
> I'm currently working on QMake plugin, more precisely shadow build
> support. So far I managed to implement a dialog window, similar to
> cmake one and the support for multiple build places.
> But some test on large projects using QMake advanced features (mainly
> QtCreator) shown some problems :
>   * Some directories in  source are not in recreated in build
> directory and marked as buildable by KDevelop (for example, "doc"
> folder in QtCreator)

Creating directories in the builddir is not the job of the qmake plugin.
The qmake plugin should only create the builddir and run qmake in it.
Buildfolders (those with the small tool on the folder icon) should be
all those that have a .pro file in the source tree.

And yes, the qmake plugin probably misses support for some of the
advanced qmake features (as explained in

>   * Most of identified targets are not targets in generated Makefiles,
> so when you try to build them with 'make <target name>', you got an
> error message

This should probably be solved by not blindly forwarding build()
requests from the qmake builder to the makebuilder. Maybe there's a way
to find the correct make target given a qmake target name (from the .pro

> Since I'm quite inexperienced with advanced QMake features, do you
> have any clue to what I shold looking for solve these problems ?
> (particularly how to make more than 1 target per directory, and how
> this is translated on final Makefile)

Look at the generated Makefile and try to understand what it does, I
don't think they're that complex. You should be able to find the actual
executable/library that is being created and from that you can get the
makefile target. As far as the advanced qmake features go, there's the
above mentioned website, the qmake manual and if both fail the source.
Its not that much source code if you ignore the actual generators, most
of qmake's logic is in qmake's language anyway (i.e. the mkspecs).

I don't actually know the current state of the code wrt. evaluating the
actual value of variables in particular when scopes and function calls
are invoked, so I can't really give you a hint how to properly implement
some of the advanced features.


Perfect day for scrubbing the floor and other exciting things.

More information about the KDevelop-devel mailing list