[PyKDE] SIP questions

Jim Bublitz jbublitz at nwinternet.com
Thu May 29 21:37:00 BST 2003


On Thursday May 29 2003 09:20, Gerard Vermeulen wrote:
> On Thu, 29 May 2003 08:40:21 -0700

> Jim Bublitz <jbublitz at nwinternet.com> wrote:
> > On Thursday May 29 2003 07:08, Jonathan Gardner wrote:
> > > On Tuesday 25 March 2003 14:05, Jim Bublitz wrote:
> > > > sip still generates one cpp/h file pair per class, but
> > > > how you distribute classes over sip files makes no
> > > > difference to anything. Every class needs a %HeaderCode
> > > > block though, no matter how you arrange things.

> > > I hate to disagree with you, Jim, and I know I am probably
> > > the one who is wrong here, but I've found that at least
> > > for 3.5, this isn't true. Here is what I have in my sip
> > > file for PostgeSQL:

> > > %HeaderCode
> > > #include "libpq-fe++.h" // My C++ wrapper around
> > > libpq-fe.h %End

> > > class result {
> >  	...
> >
> > > };
> > >
> > > class Conn {
> > > 	...
> > > };

> > > Everything seems to work okay, even though I only have one
> > > %HeaderCode block and it is outside the classes.

> > > Correct me if I am wrong.

> > I'll take your word that it works. It may be that sip has
> > changed and I'm not aware of it (although I don't think so).
> > It's more likely that the dependencies are getting satisfied
> > via some feature of the Makefile or sequence of compilation.
> > For example, if PyKDE is built using the -c switch to
> > build.py, that doesn't guarantee it will build *without* the
> > -c switch, because the way the h files are pulled in is
> > different in each case.  Similarly, if your wrapper h file
> > pulls in all of the other necessary h files and in turn the
> > wrapper h file is pulled in by another file common to all
> > the cpp files, you won't see a need for a header code block
> > in each class. However, generally I believe that's still a
> > requirement - it seems to me to be the difference between
> > "works sometimes" and "always works".

> > In general, I still get the best results by adding a
> > %HeaderCode block to each class.

> PyQwt always worked with %HeaderCode blocks outside the class
> definition (my motivation is not to confuse emacs' C++-mode).
> A quick look in the PyQwt's generated code shows that all
> files included in the %HeaderCode block end up in a file
> called 'sipqwtDeclqwt.h' and this file gets included in every
> generated *.cpp file.

I expect the situation is that %HeaderCode blocks in global space 
end up in the sip<module>Decl<module>.h file - for PyKDE that's 
very few h files, but I put the %HeaderCode blocks in the 
classes, as does PyQt. I'm not sure if this was always the case 
(or that it always will be either). PyKDE runs into a lot of 
problems making sure h files are declared in sequence (or 
declared at all in some cases - sometimes an h file relies on a 
prior #include in the cpp file which sip/PyKDE never sees).

Assuming everything else is equal, the only downside I can see of 
NOT putting header code blocks in classes is that every cpp file 
will include *every* h file, which for larger projects like PyQt 
or PyKDE might be significant overhead (without -c).

> PyQwt does not use the equivalent of a -c switch, but I do not
> think that it would make a difference in view of those
> observations.

Probably not.

Jim




More information about the PyQt mailing list