Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #10106 > unrolled thread

compiling qt app extensions with distutils

Back to article view | Back to comp.lang.python

Contents

  compiling qt app extensions with distutils strattonbrazil <strattonbrazil@gmail.com> - 2011-07-22 06:43 -0700
    Re: compiling qt app extensions with distutils Thomas Jollans <t@jollybox.de> - 2011-07-22 16:29 +0200
      Re: compiling qt app extensions with distutils strattonbrazil <strattonbrazil@gmail.com> - 2011-07-22 09:22 -0700
        Re: compiling qt app extensions with distutils Thomas Jollans <t@jollybox.de> - 2011-07-22 20:43 +0200
          Re: compiling qt app extensions with distutils strattonbrazil <strattonbrazil@gmail.com> - 2011-07-22 12:37 -0700
            Re: compiling qt app extensions with distutils Thomas Jollans <t@jollybox.de> - 2011-07-23 02:30 +0200

#10106 — compiling qt app extensions with distutils

I'd like to extend my C++ Qt applicaition using distutils.  Looking
over the tutorial docs (http://docs.python.org/extending/
building.html#building), it seems fairly intuitive for simple
examples, but I'm already using a rather complex qmake/Makefile system
to get all my cpp files and libraries included.  Is it possible to
take advantage of the existing makefile (http://pastebin.com/
Ln3NCkNL)?

[toc] | [next] | [standalone]

#10108

On 22/07/11 15:43, strattonbrazil wrote:
> I'd like to extend my C++ Qt applicaition using distutils.  Looking
> over the tutorial docs (http://docs.python.org/extending/
> building.html#building), it seems fairly intuitive for simple
> examples, but I'm already using a rather complex qmake/Makefile system
> to get all my cpp files and libraries included.  Is it possible to
> take advantage of the existing makefile (http://pastebin.com/
> Ln3NCkNL)?

What do you want to do?

Distutils is used to build extension modules. Do you want to turn your
application into a Python module?

It seams more likely that you want to embed Python in your application,
in which case you're looking at altogether the wrong documentation and
you simply have to link with libpythonX.Y like any other library

[toc] | [prev] | [next] | [standalone]

#10115

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.

Like I said, the article made sense in theory, but at the same time I
have limited time to work on my project and don't want to spend too
much time trying to figure out out to create a Qt extension--
especially since it looks like few others have actually done it.  Is
there a way to build a simple python module from my existing
makefile?  Or should I just stick with embedding for now using the
existing makefile?  Thanks.

On Jul 22, 7:29 am, Thomas Jollans <t...@jollybox.de> wrote:
> On 22/07/11 15:43, strattonbrazil wrote:
>
> > I'd like to extend my C++ Qt applicaition using distutils.  Looking
> > over the tutorial docs (http://docs.python.org/extending/
> > building.html#building), it seems fairly intuitive for simple
> > examples, but I'm already using a rather complex qmake/Makefile system
> > to get all my cpp files and libraries included.  Is it possible to
> > take advantage of the existing makefile (http://pastebin.com/
> > Ln3NCkNL)?
>
> What do you want to do?
>
> Distutils is used to build extension modules. Do you want to turn your
> application into a Python module?
>
> It seams more likely that you want to embed Python in your application,
> in which case you're looking at altogether the wrong documentation and
> you simply have to link with libpythonX.Y like any other library

[toc] | [prev] | [next] | [standalone]

#10132

On 22/07/11 18:22, strattonbrazil wrote:
> 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.

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.

It may also be possible to subclass the distutils Extension class and
let it invoke your existing build system.

You could also turn your application into a library independent of
Python with your existing build infrastructure, and create a separate
Python module, with distutils, that links in turn to that library. This
would make building your project a two-part process, of course.

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.

> 
> Like I said, the article made sense in theory, but at the same time I
> have limited time to work on my project and don't want to spend too
> much time trying to figure out out to create a Qt extension--
> especially since it looks like few others have actually done it.  Is
> there a way to build a simple python module from my existing
> makefile?  Or should I just stick with embedding for now using the
> existing makefile?  Thanks.
> 
> On Jul 22, 7:29 am, Thomas Jollans <t...@jollybox.de> wrote:
>> On 22/07/11 15:43, strattonbrazil wrote:
>>
>>> I'd like to extend my C++ Qt applicaition using distutils.  Looking
>>> over the tutorial docs (http://docs.python.org/extending/
>>> building.html#building), it seems fairly intuitive for simple
>>> examples, but I'm already using a rather complex qmake/Makefile system
>>> to get all my cpp files and libraries included.  Is it possible to
>>> take advantage of the existing makefile (http://pastebin.com/
>>> Ln3NCkNL)?
>>
>> What do you want to do?
>>
>> Distutils is used to build extension modules. Do you want to turn your
>> application into a Python module?
>>
>> It seams more likely that you want to embed Python in your application,
>> in which case you're looking at altogether the wrong documentation and
>> you simply have to link with libpythonX.Y like any other library
> 

[toc] | [prev] | [next] | [standalone]

#10144

> > 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.

[toc] | [prev] | [next] | [standalone]

#10161

On 22/07/11 21:37, strattonbrazil wrote:
>> 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.

There's no difference between using C and C++. Obviously, you always
need the correct extern "C" declarations, but IIRC, Python's method
definition macros handle that.

You could convert your whole application to a Python extension module,
expose the main function to Python, and launch the program using a small
Python wrapper script. (Or you could embed Python in your application.)

> 
>> 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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web