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

Hans-Peter Jansen hpj at urpla.net
Thu Dec 9 20:09:11 GMT 2010


On Thursday 09 December 2010, 17:49:25 Phil Thompson wrote:
> On Wed, 8 Dec 2010 13:41:42 +0100, "Hans-Peter Jansen"
> <hpj at urpla.net>
>
> > export CXXFLAGS="$RPM_OPT_FLAGS"
> > export CFLAGS="$RPM_OPT_FLAGS"
>
> What affect will these have?

None, unfortunately. I've just tried with the QMAKE_* variants, but that
doesn't work either.

> > 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).

Nice.

> > 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?

Yes. I really detest messing around with sed to get consistent builds.

One possible appoach to get this out of the way is to use your template system as done with designer/python.pro-in for the other project files, too, e.g.:

[excerpt from qpy/QtCore/qpycore.pro]

CONFIG(debug, debug|release) {
    mac: TARGET = $$join(TARGET,,,_debug)
    win32: TARGET = $$join(TARGET,,d)
}

QMAKE_CFLAGS += @CFLAGS@
QMAKE_CXXFLAGS += @CXXFLAGS@

# Python's type system relies on type punning.
!win32: QMAKE_CXXFLAGS += -fno-strict-aliasing

> > 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.

With the suggested approach the gap between them could be made very small. Would that be an acceptable intermediate approach?

Pete


More information about the PyQt mailing list