[Patch] Qmake project manager Qt module include paths

[Andreas Pakulat]

On 12.04.09 01:47:02, Andreas Pakulat wrote:
> 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.

Just as a short addition, I've just refound (by accident) that b) is not
really needed as QMake does this already.  See QTDIR/mkspecs/features/
there's a lot of .prf files there that provide various kinds of
features. And the start is usually qt_config.prf (at least for
linux-g++). Those files also declare quite some functions, IIRC the only
things that qmake doesn't implement with its own language are
string-list manipulations, variable-substitution (including regex) and
file-info-stuff, i.e. does file exist.

Andreas

-- 
Tomorrow will be cancelled due to lack of interest.