I changed the subject for this particular issue

> Then please use a more standard module. Please use qtsvg for this testing. 
> This removes a very complicated variable (the qtwebengine buildsystem).


This did help, but even more so using qmake's -d flag.

So my observations was that the *installed* qmake would ignore the mkspec that 
I gave when parsing a .pro file somewhere in a virgin Qt source tree, for 
instance qtsvg.pro . This made it impossible to do a 32bit build, but I even 
tried using linux-g++ and could confirm that the compiler invoked in the 
resulting Makefile was still g++ and not clang++ . Trying the same qmake on a 
random example .pro file outside the Qt tree didn't lead to these observations: 
there the mkspec was perfectly respected.

I now discovered that the installed mkspec/qmodule.pri is to blame for this, so 
it is probably NOT the same issue as the one I'm having trying to build Qt 
5.3.2 on OS X 10.6 (in that case there is no installed qmodule.pri, and if 
there were it shouldn't be read).

- the reason the compiler settings from the mkspec are ignored is because 
qmodule.pri contains QMAKE_CC and QMAKE_CXX definitions. I don't know why those 
variables get set in there; are they taken from the CC and CXX env. variables 
(that are set by the MacPort environment in which my build takes place)?

- The reason the -arch i386 options from macx-clang-32 don't make it into the 
Makefile is because qmodule.pri also sets QMAKE_CFLAGS and QMAKE_CXXFLAGS . Not 
with a '+=', but with a straight assignment. The values that get set are ones I 
do specify through the environment.

It surprises me that these settings from qmodule.pri override the settings in 
the mkspec; shouldn't that file provide a base setting that is then expanded 
upon or overriden by the mkspec?

Also, in my experience build systems usually take the values from the CFLAGS 
and CXXFLAGS env. variables in addition to any options they set themselves (too 
often they end up in front, meaning that a -O3 you specify in CXXFLAGS will get 
overridden by the -O2 or -Os from the configure or cmake call). Why is it that 
Qt doesn't set QMAKE_CFLAGS and QMAKE_CXXFLAGS with '+=' in qmodule.pri? I 
tried; with the += operator all options set by qmake are preserved, including 
in this case -arch i386 .

I can confirm that qmake indeed works as expected outside the Qt tree. This is 
because it does not include qmodule.pri at all.

R.
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to