compiling qt app extensions with distutils

strattonbrazil strattonbrazil at gmail.com
Fri Jul 22 15:37:08 EDT 2011


> > I have a simple Qt app that renders a scene in OpenGL does some very
> > basic geometry routines.  I originally was planning extending my app
> > just by including Python.h and the corresponding lib possibly using
> > pythonqt, but every time I brought it up on the python mailing list,
> > many would say I should be extending it instead usually referencing
> > this article (http://twistedmatrix.com/users/glyph/rant/
> > extendit.html).  The article makes pretty good sense in most cases.  I
> > could see the value of extending it as a module if my app ever wanted
> > to be used a library, but then I would have to do the whole business
> > of making a complex setup.py file to match the current Makefile.  I
> > can't find any other docs on doing this to a Qt app/library though
> > (especially since Trolltech uses the terms "extend" and "embed"
> > interchangeably).  The article does seem to glean over the
> > difficulties of extending a complex app and the python docs, at least,
> > seem to present "embedding" python as just a viable and worthwhile
> > option.
>
> Okay, your terminology was confused: you want to extend Python, not your
> application.

Sorry, after I sent that e-mail, I realized I had already mixed up the
terms, where I should have written "embedding".

> First of all, you don't technically need distutils: an extension module
> is simply a shared library that you can build like any other library,
> and I'm sure your build system can easily handle that. Then, you can
> probably use bits of distutils to figure out where to install things to.

Hrmm, this seems like the most practical solution for me right now.
It makes sense to embed python in my application like I originally
planned, where I expose the individual functions I want to expose.
Eventually if I actually want to provide the exposed functions as a
library, I could actually just compile the application to a shared
library instead of an executable (just not using the main function).
The bindings in the C++ code are the same, correct?  Only the way
they're built seems different.

> Lastly, depending on what your goals are, you might want to consider not
> integrating Python with your application at all, but exposing what
> functionality you want to expose to Python via dbus. You could write a
> skeleton module that exposes dbus proxy objects to Python scripts /
> modules to make life easier.



More information about the Python-list mailing list