Status of Qt4 qmake support

Hi,

this is more or less a status update and RFC.

I'm so far done with the "important" stuff,
i.e. properly parsing the QT
variable, supporting resource files and cleaning up the
configuration
dialog for qmake projects. I'm going to try to add a
"qt4" option to the
import wizard when the project is a qmake project tonight.

The kdevelop-qmake4 branch is near to ready for a merge, as
the next
changes will take quite some time and possibly won't make
it into
kdevelop3.4 (using the qmake parser instead of the
regexp-parsing that
exists atm).

Before merging there are a couple of questions that I'd
like to resolve:

- upgrade-path for existing projects
	One problem is that the designer-integration setting
changed and
	I have absolutely no idea how or if it is possible to take
over
	the existing setting into the project. The other
upgrade-problem
	is that the include-style will on upgrades define the Qt
	version, as in earlier versions of KDevelop qt/version was
used
	for the include style option.

- project settings change affects qmake manager ui
	I asked this on IRC but got no response. If a user switches
from
	Qt3 to Qt4 inside the project options, the qmake manager
ideally
	should change it's ui (replacing IMAGES with RESOURCES),
however
	I don't know wether this is possible.

Hints on those two are welcome.

Andreas

-- 
You are wise, witty, and wonderful, but you spend too much
time reading
this sort of trash.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/
kdevelop-devel

First THANK YOU!  I have been wanting time to fix this
myself, but have not 
had an opportunity.  As a point of curiosity do you have any
ideas on how to 
handle PRI support.  We use them quite extensively at work,
and they can 
often confuse KDevelop when you include source files in
them.   Also, do you 
think the custom variable stuff I attempted is salvageable
to work for custom 
build steps?

On Sunday 30 July 2006 13:12, Andreas Pakulat wrote:
> Hi,
>
> this is more or less a status update and RFC.
>
> I'm so far done with the "important"
stuff, i.e. properly parsing the QT
> variable, supporting resource files and cleaning up the
configuration
[...]
> - project settings change affects qmake manager ui
> 	I asked this on IRC but got no response. If a user
switches from
> 	Qt3 to Qt4 inside the project options, the qmake
manager ideally
> 	should change it's ui (replacing IMAGES with
RESOURCES), however
> 	I don't know wether this is possible.
Automagic conversions IMHO can be problems because if we do
the wrong things 
users get pissed.  Or is this not what you are getting at? 
Is this just a 
cosmetic level of things, or something more advanced?

Cheers
	-ian reinhart geiser

_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/
kdevelop-devel

On 30.07.06 15:39:30, Ian Reinhart Geiser wrote:
> As a point of curiosity do you have any ideas on how to

> handle PRI support.

I don't even know what PRI's are. If you have some docs
explaining them,
I could see what I can do...

>  We use them quite extensively at work, and they can
often confuse
>  KDevelop when you include source files in them.

Hmm, in what way exactly? From what I've seen so far,
they're just
ignored by the qmake manager (or should be). However I
haven't looked
into the "logic" stuff too much (i.e. handling
include-directives and
such).

> Also, do you think the custom variable stuff I
attempted is
> salvageable to work for custom build steps?

I have absolutely no idea, luckily I didn't need to dive
too deep into
the non-gui code (yet).

> On Sunday 30 July 2006 13:12, Andreas Pakulat wrote:
> > Hi,
> >
> > this is more or less a status update and RFC.
> >
> > I'm so far done with the "important"
stuff, i.e. properly parsing the QT
> > variable, supporting resource files and cleaning
up the configuration
> [...]
> > - project settings change affects qmake manager ui
> > 	I asked this on IRC but got no response. If a
user switches from
> > 	Qt3 to Qt4 inside the project options, the qmake
manager ideally
> > 	should change it's ui (replacing IMAGES with
RESOURCES), however
> > 	I don't know wether this is possible.
> Automagic conversions IMHO can be problems because if
we do the wrong things 
> users get pissed.  Or is this not what you are getting
at?  Is this just a 
> cosmetic level of things, or something more advanced?

What I did is: for the subproject-view (i.e. where you have
the FORMS,
SOURCES, HEADERS and so on) I add the IMAGES variable only
for Qt3
projects and the RESOURCES only for Qt4 (I couldn't find
IMAGES in qt4
qmake doc and qt3 has no RESOURCES). However the listview is
of course
only built once upon project loading, thus when you open a
project and
then switch from qt3 to qt4, you won't get the RESOURCES
variable until
you reload the project. So what I'd need would be some
signal that I
could attach to a slot of the project manager to update the
listview.

The manage currently doesn't remove IMAGES from a qt4
project or
RESOURCES from a qt3 project, they should show up as custom
variables
(RESOURCES did until I integrated them).

Andreas

-- 
It's lucky you're going so slowly, because you're going
in the wrong direction.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/
kdevelop-devel

On 30.07.06 23:05:59, Andreas Pakulat wrote:
> On 30.07.06 15:39:30, Ian Reinhart Geiser wrote:
> > Also, do you think the custom variable stuff I
attempted is
> > salvageable to work for custom build steps?
> 
> I have absolutely no idea, luckily I didn't need to
dive too deep into
> the non-gui code (yet).

I think custom variables should work. What I don't know if
it works atm
is something like this:

CONFIG += qt console newstuff
    ...
    newstuff {
        SOURCES += new.cpp
        HEADERS += new.h
    }

I don't think it will, because the current
"parser" won't remember that
newstuff was set. We probably need the qmake parser+AST for
that (well
it could be done with the current stuff, but IMHO the work
is not worth
it).

If you have example projects (either qt3 or qt4) that you
can share (via
PM if you like) that would be really great. I guess in most
cases you
can just rip off any source files and it will still be
useful.

A quick test with a custom variable that is used inside the
contains
function to provide a custom scope worked so far.

Andreas

-- 
Today is National Existential Ennui Awareness Day.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/
kdevelop-devel

On Sunday 30 July 2006 17:05, Andreas Pakulat wrote:
> On 30.07.06 15:39:30, Ian Reinhart Geiser wrote:
> > As a point of curiosity do you have any ideas on
how to
> > handle PRI support.
>
> I don't even know what PRI's are. If you have some
docs explaining them,
> I could see what I can do...
PRI files are basicly include files for .pro files.  You can
use the 
include(...) function in QMake to use them.  Syntacticly
they are identical 
to .pro files.  I got stuck as to how to edit them via the
GUI. Should they 
be children of the project in the QMake project treeview? 
Or maybe a 
seperate dialog.  Even if I could not edit them via the GUI
though, just 
having them parsed for SOURCE, HEADERS and UI files would be
a big win.  The 
big problem is if we don't then KDevelop never knows about
those files, and 
they wont appear in the class view.

Hope this clears things up.

Cheers
	-ian reinhart geiser


_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/
kdevelop-devel

On 31.07.06 08:47:33, Ian Reinhart Geiser wrote:
> On Sunday 30 July 2006 17:05, Andreas Pakulat wrote:
> > On 30.07.06 15:39:30, Ian Reinhart Geiser wrote:
> > > As a point of curiosity do you have any ideas
on how to
> > > handle PRI support.
> >
> > I don't even know what PRI's are. If you have
some docs explaining them,
> > I could see what I can do...
> PRI files are basicly include files for .pro files. 
You can use the 
> include(...) function in QMake to use them. 
Syntacticly they are identical 
> to .pro files.

Thanks.

> I got stuck as to how to edit them via the GUI. Should
they 
> be children of the project in the QMake project
treeview?  Or maybe a 
> seperate dialog.

I would do this the same way scopes work, i.e. a new leaf
under the
subproject with a proper new icon. 

> Even if I could not edit them via the GUI though, just 
> having them parsed for SOURCE, HEADERS and UI files
would be a big win.

There's a comment inside the trollprojecwidget about
pri-parsing,
however no code and currently I'm rather reluctant about
changing that.
I'd much more like to work on integrating the AST from the
qmake parser,
which would simplify this a lot.

>  The big problem is if we don't then KDevelop never
knows about those
>  files, and they wont appear in the class view.

Yeah, the automake manager has similar
"problems" with conditional
sub-projects, i.e. the list of directories is
"calculated" at configure
time and thus the automake manager doesn't show any classes
inside those
directories in the class view.

Let's see how far I get in the next couple of days...

Andreas

-- 
You have no real enemies.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/
kdevelop-devel

On Monday 31 July 2006 09:09, Andreas Pakulat wrote:
> On 31.07.06 08:47:33, Ian Reinhart Geiser wrote:
> > On Sunday 30 July 2006 17:05, Andreas Pakulat
wrote:
> > > On 30.07.06 15:39:30, Ian Reinhart Geiser
wrote:
[...]
> > Even if I could not edit them via the GUI though,
just
> > having them parsed for SOURCE, HEADERS and UI
files would be a big win.
>
> There's a comment inside the trollprojecwidget about
pri-parsing,
> however no code and currently I'm rather reluctant
about changing that.
> I'd much more like to work on integrating the AST from
the qmake parser,
> which would simplify this a lot.
Hrm, I hope I didn't add that comment :P  Yeah going the
AST route is an 
infinitely better solution.  From what I remember the AST
will be what is 
used in KDevelop 4 (I am assuming you are working in
KDevelop 3.4 right now, 
correct?) so this is the best way to go.  I harbor a secret
hatred for the 
regexp parser, even though I helped keep it around this long


> >  The big problem is if we don't then KDevelop
never knows about those
> >  files, and they wont appear in the class view.
>
> Yeah, the automake manager has similar
"problems" with conditional
> sub-projects, i.e. the list of directories is
"calculated" at configure
> time and thus the automake manager doesn't show any
classes inside those
> directories in the class view.
>
> Let's see how far I get in the next couple of days...
If there is any stupid stuff I can do to help let me know. 
I have a few 
examples that currently piss off KDevelop and MSVC   I also
have a few 
senarios with project scopes that confuse our current
parser.  I attempted to 
add edit support for scopes, but I think the regexp parser,
along with the 
old "ill randomly reorder lines when I dump the .pro
file" feature made it 
very confusing to me. 

Cheers
	-ian reinhart geiser


_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/
kdevelop-devel

On Sunday 30 July 2006 17:42, Andreas Pakulat wrote:
> On 30.07.06 23:05:59, Andreas Pakulat wrote:
> > On 30.07.06 15:39:30, Ian Reinhart Geiser wrote:
> > > Also, do you think the custom variable stuff
I attempted is
> > > salvageable to work for custom build steps?
> >
> > I have absolutely no idea, luckily I didn't need
to dive too deep into
> > the non-gui code (yet).
>
> I think custom variables should work. What I don't
know if it works atm
> is something like this:
>
> CONFIG += qt console newstuff
>     ...
>     newstuff {
>         SOURCES += new.cpp
>         HEADERS += new.h
>     }
>
> I don't think it will, because the current
"parser" won't remember that
> newstuff was set. We probably need the qmake parser+AST
for that (well
> it could be done with the current stuff, but IMHO the
work is not worth
> it).
Yeah, I think I had problems there when I was working out
some KDE 3 pri files 
so I could use dcop and kconfigxt from QMake.  

> If you have example projects (either qt3 or qt4) that
you can share (via
> PM if you like) that would be really great. I guess in
most cases you
> can just rip off any source files and it will still be
useful.
I will try to tar up a few bananas of gold.  I have to admit
I love the QMake 
build system, so I use it for everything.

> A quick test with a custom variable that is used inside
the contains
> function to provide a custom scope worked so far.
I think simple cases should work, at least all the ones I
had at the time 
did 

Cheers
	-ian reinhart geiser

_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/
kdevelop-devel

On 31.07.06 11:03:35, Ian Reinhart Geiser wrote:
> On Monday 31 July 2006 09:09, Andreas Pakulat wrote:
> > On 31.07.06 08:47:33, Ian Reinhart Geiser wrote:
> > > On Sunday 30 July 2006 17:05, Andreas Pakulat
wrote:
> > > > On 30.07.06 15:39:30, Ian Reinhart
Geiser wrote:
> [...]
> > > Even if I could not edit them via the GUI
though, just
> > > having them parsed for SOURCE, HEADERS and UI
files would be a big win.
> >
> > There's a comment inside the trollprojecwidget
about pri-parsing,
> > however no code and currently I'm rather
reluctant about changing that.
> > I'd much more like to work on integrating the AST
from the qmake parser,
> > which would simplify this a lot.
> Hrm, I hope I didn't add that comment :P  Yeah going
the AST route is an 
> infinitely better solution.  From what I remember the
AST will be what is 
> used in KDevelop 4 (I am assuming you are working in
KDevelop 3.4 right now, 
> correct?)

Right, I didn't delve into anz KDE4 (yet)... 

> so this is the best way to go.  I harbor a secret
hatred for the 
> regexp parser, even though I helped keep it around this
long 

Well, I have a strong dislike for any "regexp
parser" for anything more
complex than simple ini-files (i.e. a group with a list of
variable
assignment). 

> > >  The big problem is if we don't then
KDevelop never knows about those
> > >  files, and they wont appear in the class
view.
> >
> > Yeah, the automake manager has similar
"problems" with conditional
> > sub-projects, i.e. the list of directories is
"calculated" at configure
> > time and thus the automake manager doesn't show
any classes inside those
> > directories in the class view.
> >
> > Let's see how far I get in the next couple of
days...
> If there is any stupid stuff I can do to help let me
know. 

I guess not, at least I don't see anything at the moment.

> I also have a few 
> senarios with project scopes that confuse our current
parser. 

Which rather tells one that the parser is
"lacking", then that the
projects are "complex". BTW: the parser
currently cannot properly handle
function scopes, it removes the scope when writing the file
back, but
the AST-parser can handle it.

> I attempted to add edit support for scopes, but I think
the regexp
> parser, along with the old "ill randomly reorder
lines when I dump the
> .pro file" feature made it very confusing to me. 

Well, it does work for the CONFIG(debug,debug|release) {}
scopes, at
least it doesn't screw that.

Thanks for your input, looking forward to the project
examples from you
as test-base.

Andreas

-- 
You have a truly strong individuality.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/
kdevelop-devel