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

[Hans-Peter Jansen]

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