[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