[PyKDE] SIP-4.0rc1 minor build /install issues

Phil Thompson phil at riverbankcomputing.co.uk
Sat Dec 13 12:19:01 GMT 2003


On Friday 12 December 2003 7:29 am, Jon Dyte wrote:
> On Thursday 11 December 2003 22:26, Phil Thompson wrote:
> > On Thursday 11 December 2003 8:38 pm, Jon Dyte wrote:
> > > Hi
> > > I've been building SIP-4.0rc1 without Qt.
> > >
> > > I get this failure on make install despite supplying -b and -d on the
> > > command line eg python configure.py -b /sw/sip4 -d /sw/sip4/python2.3
> > > -x
> > >
> > > make[1]: Entering directory `/home/jon/sip-4.0rc1/siplib'
> > > cp -f sip.so /sw/sip/python2.3/sip.so
> > > cp -f sip.h /usr/include/python2.3/sip.h
> > > cp: cannot create regular file `/usr/include/python2.3/sip.h':
> > > Permission denied make[1]: *** [install] Error 1
> > > make[1]: Leaving directory `/home/jon/sip-4.0rc1/siplib'
> > > make: *** [install] Error 2
> > >
> > >
> > > I fixed this by altering configure.py
> > > at line 711
> > > 	elif opt == "-d":
> > >             opt_sipmoddir = arg
> > > 	    opt_sipincdir = arg + "/include"
> > >
> > > this puts the sip headers in an include directory below whereever the
> > > -d option was specified. I'm not sure if this is the best way to fix
> > > this or not, but certainly there will be cases where people cannot
> > > install into the python directory tree.
> >
> > Use the -e flag. The reason you didn't notice it is because it's missing
> > from the help text.
>
> Thanks for the pointer!!!
>
> > > On Solaris I found that regardless of whether -x was specified the
> > > build still barfed if QTDIR wasnt set. In the end I set QTDIR to
> > > /zzzzzz to make the error go away.
> > >
> > > Also on Solaris I had to make the sipSetBool function in qtlib.cpp be
> > > declared extern "C" else the module would complain about missing
> > > symbols when being imported. This might be due to my python build on
> > > Solaris or the version of CC (4.2) installed. (That particular CC is
> > > also missing a bool type which I had to define to get the file to
> > > compile as well). It looks like a name mangling issue anyhow.
>
> In the end I figured the extern "C" issue only occurs when building without
> Qt, because the includes in qtlib.cpp dont get included and they wrap the
> api in an extern "C" when its a c++ compiler. I fixed that with
> a minor reordering at the top of qtlib.cpp......
> /* moved to be always included regardless of Qt support or not*/
>
> #include <Python.h>
> #include <string.h>
> #include "sip.h"
> #include "sipint.h"
>
> #ifdef SIP_QT_SUPPORT
>
> #include <qobject.h>
>
> > Should be fixed in tonight's snapshot.
> >
> > Is there a "standard" way of handling the case where the C++ compiler
> > doesn't support the bool type?
>
> Well I just put in the source
>
> #ifndef bool
> typedef bool int;
> const bool true =1;
> const bool false=0;
> #endif
>
> in one of the headers.
>
> it might be safer to have a type sipBool and define it to either be a
> genuine C++ bool if that exists, or typedef an int?

I meant is there a standard way of testing if bool is supported?

Phil




More information about the PyQt mailing list