[PyQt] compile flags propagation WAS: RE: PyQt snapshot debug info

Hans-Peter Jansen hpj at urpla.net
Wed Dec 8 12:41:42 GMT 2010


On Tuesday 07 December 2010, 20:41:42 Hans-Peter Jansen wrote:
> On Tuesday 07 December 2010, 18:21:16 Phil Thompson wrote:
> > On Mon, 6 Dec 2010 21:57:15 +0100, "Hans-Peter Jansen"
> > <hpj at urpla.net>
> >
> > >PyQt-x11-gpl-snapshot-4.8.2-24a6ba5f4f0f/qpy/QtDeclarative/QtDecla
> > >rative/sipAPIQtDeclarative.h: Cannot stat: No such file or
> > > directory
> > >
> > > Okay, I missed the *.h files, but that nicely shows the
> > > difference
> > >
> > > :-)
> > >
> > > Convinced?
> >
> > Try tonight's snapshots which ensure that all #lines have absolute
> > pathnames.
>
> They get picked up automatically, but I will check the build logs
> tomorrow.
>

Okay, debug info is mostly fine again, thanks.

Looking into the other checks reveals some smaller issues remaining:

... testing for serious compiler warnings
    (using /usr/lib/build/checks-data/check_gcc_output)
    (using /var/tmp/build-root/.build.log)

I: File is compiled without RPM_OPT_FLAGS
W: python-qt4 no-rpm-opt-flags <cmdline>:qpydeclarative_listwrapper.cpp, qpydeclarative_post_init.cpp, qpydeclarativelistproperty.cpp, 
moc_qpydeclarativepropertyvaluesource.cpp, moc_qpydeclarative_listwrapper.cpp, qpycore_chimera.cpp, qpycore_chimera_signature.cpp, 
qpycore_chimera_storage.cpp, qpycore_init.cpp, qpycore_misc.cpp, qpycore_post_init.cpp, qpycore_pyqtboundsignal.cpp, qpycore_pyqtconfigure.cpp, 
qpycore_pyqtproperty.cpp, qpycore_pyqtproxy.cpp, qpycore_pyqtpyobject.cpp, qpycore_pyqtsignal.cpp, qpycore_pyqtslot.cpp, 
qpycore_qmetaobject.cpp, qpycore_qmetaobject_helpers.cpp, qpycore_qobject_helpers.cpp, qpycore_qstring.cpp, qpycore_qstringlist.cpp, 
qpycore_sip_helpers.cpp, qpycore_types.cpp, qpycore_qvariant.cpp, moc_qpycore_pyqtproxy.cpp, moc_qpytextobject.cpp, 
moc_qpydesignercontainerextension.cpp, moc_qpydesignermembersheetextension.cpp, moc_qpydesignerpropertysheetextension.cpp, 
moc_qpydesignertaskmenuextension.cpp, moc_qpydesignercustomwidgetplugin.cpp, moc_qpydesignercustomwidgetcollectionplugin.cpp, pluginloader.cpp, 
moc_pluginloader.cpp

This is strange, since PyQt gets configured/built this way:

export CXXFLAGS="$RPM_OPT_FLAGS"
export CFLAGS="$RPM_OPT_FLAGS"
python configure.py \
    --confirm-license \
    --qsci-api \
    --debug \
    CFLAGS+="$RPM_OPT_FLAGS" \
    CXXFLAGS+="$RPM_OPT_FLAGS"
make %{?jobs:-j %jobs}

Then I noticed, that there's another way to provide the C{,XX}FLAGS:

QMAKE_C{,XX}FLAGS += $RPM_OPT_FLAGS

but trying to provide them as additional macros lead to configure.py 
bailing out with a usage print:

+ python configure.py --confirm-license --qsci-api --debug \
 'CFLAGS+=-march=i586 -mtune=i686 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g'
 'CXXFLAGS+=-march=i586 -mtune=i686 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g'
 'QMAKE_CFLAGS+=-march=i586 -mtune=i686 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g' 
 'QMAKE_CXXFLAGS+=-march=i586 -mtune=i686 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g'
Determining the layout of your Qt installation...
Usage: python configure.py [opts] [macro=value] [macro+=value]
[...]

Okay, now do it the dirty way (in prepare stage):

# propagate RPM_OPT_FLAGS to all modules
for f in $(find . -name \*.pro\*); do
    echo $f | grep -q "_w" && continue
    sed -i "1i\\
QMAKE_CFLAGS += $RPM_OPT_FLAGS \\
QMAKE_CXXFLAGS += $RPM_OPT_FLAGS \\

" $f
done

This inserts the QMAKE_C{,XX}FLAGS at the top of all project files.

Now, all modules are built with the expected compiler flags and the 
warning above disappeared. 

The last remaining issue was the release argument to CONFIG in 
designer/python.pro-in, which resulted in a stripped 
libpythonplugin.so, hence
sed -i 's/ release warn$/ debug warn/g' designer/python.pro-in
fixed that, too.

It would be nice to be able to build PyQt without these ugly 
encroachments, wouldn't it?

Pete


More information about the PyQt mailing list