Re: Python bindings

On Thu, Mar 06, 2003 at 06:05:30PM +0100, Richard Hult wrote:
> ons 2003-03-05 klockan 21.58 skrev Malcolm Tredinnick:
> > On Wed, Mar 05, 2003 at 12:29:15PM +0100, Mikael Hallendal wrote:
> > > Or is it just a build dependency?
> > 
> > It is just a build dependency. PyGTK has a pygtk-codegen script that
> > takes the mrproject-*.defs files (which can be used for _any_ language
> > binding -- they are a Scheme like description of the functions and
> > arguments, etc), combines them with the mrproject.overrides file (which
> > contains the hand-written wrappers for functions that require them and
> > so is Python specific) and creates a mrproject.c file of automatically
> > generated code.
> 
> I guess it's also a run-time dependency? Or does pygtk do dynamic
> loading of gtk in some way? If gtk, pango, etc, are required during
> run-time, then we might as well have it as tarball build-time
> requirement too.

OK, I am apparently not explaining this very well. Let me try again,
beginning with the binary requirements and working backwards to CVS.

(1) Once everything is built, the python bindings will depend on
libmrproject and whatever libmrproject depends upon (GLib, libxml2,
libgsf). Nothing else. No run-time dependency on GTK or anything like
that.

(2) In order to build the Python bindings, we need the file
python/mrproject.c which contains wrappers for most of the functions,
objects and types in the libmrproject public header files. The remaining
functions (those not wrapped by mrproject.c for technical reasons), are
wrapped by hand and are checked into CVS.

(3) In order to generate mrproject.c, we need to use the codegen.py
script at some point. This script is installed as part of PyGTK. The
source for it is in the gnome-python/pygtk/codegen/ directory in GNOME
CVS. The codegen stuff has no dependency on gtk or anything. It is
simply a bunch of utility scripts for automatically generating code.
They are slightly more specialised than things like SWIG, since the code
knows about GTK widgets and GObject structures and the like, so it can
do a better job with less -- that is why I am using these scripts,
rather than some other code generating tool.

So, it is not beyond the realms of possibility that James Henstridge
could ship the codegen stuff as a separate package. However, it is
currently shipped in PyGTK. The dependency there is simply to get the
tools to generate the code to build the bindings. It is just an
unfortunate packaging decision, in retrospect (to be fair, almost all
the python bindings in GNOME depend in some way on GTK, so it's not an
unreasonable requirement). That is why my current thinking is to ship
the python/mrproject.c file in the distributed tarball and only
regenerate it at build time if the tools are available. I would be
reluctant to check it into CVS, though, so PyGTK (or at least the
codegen portion) will still be required for that.

I might also talk with JamesH about packaging that stuff separately (or
at least checking in a self-contained configure and build system to CVS
so that we can jut make a codegen module in CVSROOT/modules and rely on
that for people who want it).

> In the long run, it would be nice to be able to provide bindings that
> don't have this kind of requirements though, for scenarios like the one
> Mikael talked about.

I totally agree. In fact, one of the scenarios Mikael mentioned (a cgi
script that produces something from a mrproject file) is exactly why I
started on these bindings a couple of weeks ago.

I have a slightly longer-term plan of wanting to make it possible to
write plug-ins for mrproject in Python, which _will_ require PyGTK and
friends at runtime. But at that point, it will not be an unreasonable
requirement, since if you are writing plugins in Python, you will want
to display widgets at some point, so you need the infrastructure to do
that. However, that is a way down the track yet.

If this is still not clear, please let me know and I will try again
(although I should be able to finish it up over the weekend and you will
be able to see what I am talking about).

Apologies for all the confusion,
Malcolm

-- 
Always try to be modest and be proud of it!