[Patch] Qmake project manager Qt module include paths

[Andreas Pakulat]

On 10.04.09 16:43:00, Sean Harmer wrote:
> On Friday 10 April 2009 00:38:35 Andreas Pakulat wrote:
> > On 09.04.09 14:22:26, Sean Harmer wrote:
> > > Hi All,
> > >
> > > This is my first post to this list.
> > >
> > > I have been trying to use kdevelop trunk with some of our work projects
> > > which use the qmake build manager and I was forever getting problems
> > > reported about the preprocessor not being able to resolve Qt #includes.
> >
> > Don't do that, the QMake support in trunk/ is not ready for usage and
> > will most probably be moved very soon to playground.
> Hmmm, that's a shame we use qmake a lot for our projects.

Yeah, I know. Unfortunately there are more important areas in kdevelop
that need attention first :) I'd actually like to work on qmake support
to see how full language-support for it works out. But I'd also like to
release kdevelop4 this decade...
 
> > > Upon investigation this turns out to be because the qmake manager was
> > > telling the preprocessor to add $$[QT_INSTALL_HEADERS] to the include
> > > search path but this variable is internal to qmake. However it can be
> > > resolved by calling qmake -query QT_INSTALL_HEADERS so that is what I
> > > have done in the attached patch.
> >
> > Thats not the only problem, unless I'm mistaken the qmake manager
> > currently doesn't do any variable resolving at all, so only the most
> > simple projects work.
> I think not too. I'll start reading through the source to see if I can get my 
> head around what it is doing and where it needs improving as I would like to 
> be able to use kdevelop 4 with qmake. If anybody has any hints or pointers on 
> what areas that need work that would be great.

The basic idea was to stop implementing it the way I started and instead
trying to leverage the duchain framework to do all the lookup stuff.

So the basic way of how I imagined this should work is:

a) run qmake to find out the place of the Qt installation, in particular
the include, lib and plugin dirs and most importantly the mkspecs dir
and which mkspec to use (possibly use-configurable).
b) read and parse a file shipped with kdevelop that provides the
qmake-internal functions (i.e. everything shipped by qmake via its C++
source). This most probably only needs to declare the methods, so the
other parts know they exist somewhere.
c) read and parse the files for the mkspec (qmake.conf, all the included
files), this should produce a couple base variables
d) start with the top-level qmake file from the project (this might
again need user-specification via gui which file should be used)
e) during parsing, evaluate all the known functions, so we automatically
dive into include() directives, can do variable substitution and also
the list-stuff qmake supports

Points b) to e) should on the fly register anything they encounter with
the DUChain, i.e. function declarations, variable declarations, uses of
the variables and so on. This will (hopefully) make it easy to find out
the buildsystem information at a given directory (just find the qmake
file, find the related DUChain object for the INCLUDE variables and go
backwards resolving the variables). On top of that it'll allow for
semantic highlighting and code-completion when editing .pro files.

Thats the theory, whats there right now is a full qmake parser (no known
bugs or missing features from qmake) and the start of some basic
evaluation. I've actually started with the variable substitution, but
then wanted to first go on with the DUChain integration. I've started
the stuff in the duchain/ subdir, but never really got to implement it.

I don't expect anybody to finish the above mentioned vision. At this
point I'd gladly accept patches that finalize the existing way of
resolving variables and then provide the include-dirs and compile flags
based on that. This way the support would at least be basically usable
for a release.

Andreas

-- 
People are beginning to notice you.  Try dressing before you leave the house.