[qt-dev] Recompiling Qt apps (KDiff3)

[Peter Weilbacher]

First, a BIG THANKS for the great betas of the Qt4 port. Now that
I updated to beta 4, I was amazed how easy it was, to get the build
going. With Mozilla, we have to fight a lot more. (Even though Qt4
takes even a bit longer to finish building.)

Now for the problem: while tracking down a problem in KDiff3, I
was annoyed that it always recompiled _all_ the object files and
relinked the final binary on a simple call of |make|. So for each
test I had to wait about 2 minutes before I could run the EXE to
see if the changes helped.
I don't see anything special in the kdiff3.pro file[1], so I guess
this must be a feature/problem of qmake. I also changed the
resulting Makefile.Debug/.Release quite a bit but couldn't find
out what caused even untouched files to be rebuilt.

Any ideas?
Peter.

[1] http://kdiff3.svn.sourceforge.net/viewvc/kdiff3/trunk/kdiff3/src-QT4/kdiff3.pro?revision=84&view=markup

[Dmitry A. Kuminov]

Hi Peter,

Post by Peter Weilbacher
First, a BIG THANKS for the great betas of the Qt4 port. Now that
I updated to beta 4, I was amazed how easy it was, to get the build
going. With Mozilla, we have to fight a lot more. (Even though Qt4
takes even a bit longer to finish building.)

Nice to hear that!

Post by Peter Weilbacher
Now for the problem: while tracking down a problem in KDiff3, I
was annoyed that it always recompiled _all_ the object files and
relinked the final binary on a simple call of |make|. So for each
test I had to wait about 2 minutes before I could run the EXE to
see if the changes helped.
I don't see anything special in the kdiff3.pro file[1], so I guess
this must be a feature/problem of qmake. I also changed the
resulting Makefile.Debug/.Release quite a bit but couldn't find
out what caused even untouched files to be rebuilt.

I don't see anything suspicious in kdiff3.pro and I haven't experienced anything
like that on my machine. My only idea is that some include file (version.h?)
included from every source is regenerated each time from the Makefile...

Anyway, if you tell me exactly what source tree of kdiff3 you are using, I can
try to build it locally to see if I get it here.

[Peter Weilbacher]

Post by Dmitry A. Kuminov
I don't see anything suspicious in kdiff3.pro and I haven't experienced
anything like that on my machine. My only idea is that some include file
(version.h?) included from every source is regenerated each time from
the Makefile...

Yes, that's it. There is a precompiled header {release,debug}\stable.h.gch\c++
that should get regenerated at the start of the build. But it seems GCC 3.3.5
has problems with that, so it never actually gets written:

$ make -n
make.exe -f Makefile.Debug
make.exe[1]: Entering directory `<PATH>/kdiff3-0.9.95/src-QT4'
if not exist debug\stable.h.gch "..\..\QT451b4\mkspecs\default\mkdir-p.cmd" debug\stable.h.gch
g++ -x c++-header -c -Zomf -g -Wall -DQT_GUI_LIB -DQT_CORE_LIB -I..\..\QT451b4\include\QtCore -I..\..\QT451b4\include\QtGui -I..\..\QT451b4\include -I. -Ikreplacements -Idebug -I. -I..\..\QT451b4\mkspecs\default -o debug\stable.h.gch\c++ stable.h
g++ -c -include debug\stable.h -Zomf -g -Wall -DQT_GUI_LIB -DQT_CORE_LIB -I..\..\QT451b4\include\QtCore -I..\..\QT451b4\include\QtGui -I..\..\QT451b4\include -I. -Ikreplacements -Idebug -I. -I..\..\QT451b4\mkspecs\default -o debug\main.obj main.cpp
[...]

The first g++ line outputs
g++: language c++-header not recognized
g++: stable.h: linker input file unused because linking not done
so that's the reason. If I manually
touch debug\stable.h.gch\c++
it really only compiles the file(s) that it should, but of course without
the speed gain by the precompiled header.

Cheers,
Peter.

[Peter Weilbacher]

Post by Peter Weilbacher
The first g++ line outputs
g++: language c++-header not recognized
g++: stable.h: linker input file unused because linking not done
so that's the reason. If I manually
touch debug\stable.h.gch\c++
it really only compiles the file(s) that it should, but of course without
the speed gain by the precompiled header.

Oh my! I only remember now that precompiled headers were first implemented
with GCC 3.4, so of course this has to fail with 3.3.5!
P.

[Dmitry A. Kuminov]

Post by Peter Weilbacher

Post by Peter Weilbacher
The first g++ line outputs
g++: language c++-header not recognized
g++: stable.h: linker input file unused because linking not done
so that's the reason. If I manually
touch debug\stable.h.gch\c++
it really only compiles the file(s) that it should, but of course without
the speed gain by the precompiled header.

Oh my! I only remember now that precompiled headers were first implemented
with GCC 3.4, so of course this has to fail with 3.3.5!

Right. And kdiff3.pro explicitly asks for precompiled headers in CONFIG
(precompile_header). Until we've migrated to GCC 4 and tested that precompiled
headers actually work on OS/2, I sugges that you just put:

os2:CONFIG -= precompile_header

after the original CONFIG line.

[Dave Yeo]

Post by Peter Weilbacher

Post by Peter Weilbacher
The first g++ line outputs
g++: language c++-header not recognized
g++: stable.h: linker input file unused because linking not done
so that's the reason. If I manually
touch debug\stable.h.gch\c++
it really only compiles the file(s) that it should, but of course without
the speed gain by the precompiled header.

Oh my! I only remember now that precompiled headers were first implemented
with GCC 3.4, so of course this has to fail with 3.3.5!
P.

Precompiled headers don't seem to work here with any version of GCC
Dave