On Thursday 09 December 2010, 17:49:25 Phil Thompson wrote:
> On Wed, 8 Dec 2010 13:41:42 +0100, "Hans-Peter Jansen"
> <h...@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
_______________________________________________
PyQt mailing list PyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
