[Patch] Qmake project manager Qt module include paths

[Sean Harmer]

On Sunday 12 April 2009 00:47:02 Andreas Pakulat wrote:
> On 10.04.09 16:43:00, Sean Harmer wrote:
> > 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...

I understand completely :-)

<snip>
> 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.
OK. I've been following the list and various blogs about the DUChain 
framework. I guess I have lots of reading to do... ;-)

> 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
OK I think I see what you intend.

> 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. 
I'd like to help with this but I have a lot of learning to do before I could 
be really productive I think.

> 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.
This might be the simpler and more pragmatic way forward for an initial usable 
version. I'll see what I can do.

Thanks for the explanations.

Sean