On Wed, 8 Dec 2010 13:41:42 +0100, "Hans-Peter Jansen"
wrote:
> 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"
>> >
>> >
>> > >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 :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"
What affect will these have?
> python configure.py \
> --confirm-license \
> --qsci-api \
> --debug \
> CFLAGS+="$RPM_OPT_FLAGS" \
> CXXFLAGS+="$RPM_OPT_FLAGS"
> make %{?jobs:-j %jobs}
This looks fine for configuring SIP's build system.
> Then I noticed, that there's another way to provide the C{,XX}FLAGS:
>
> QMAKE_C{,XX}FLAGS += $RPM_OPT_FLAGS
Not supported by SIP's build system.
> 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]
> [...]
I've improved the error message to say that you've specified an invalid
macro name (but it doesn't say which one).
> 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.
So the problem is only for PyQt's internal libraries that are built with
qmake, and not SIP's build system?
> 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?
Agreed that it's not clear that PyQt is using two completely separate
build tools under the covers. That will go away as part of the preparation
for SIP v5.
Phil
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
