Re: Python bindings

Malcolm Tredinnick <[email protected]> Thu, 6 Mar 2003 07:58:27 +1100
Newsgroups gmane.comp.gnome.apps.mr-project.devel
Message-ID <[email protected]>
On Wed, Mar 05, 2003 at 12:29:15PM +0100, Mikael Hallendal wrote:
> ons 2003-03-05 klockan 10.40 skrev Richard Hult:
> > ons 2003-03-05 klockan 03.38 skrev Malcolm Tredinnick:
[...]
> > > Richard, Mikael: there is an implicit dependency on PyGTK for building
> > > this stuff. I will set it up so that things will quietly fail (just not
> > > build the bindings) if PyGTK is not installed, but do you think it is
> > > too onerous to require this to make the bindings build work? The reason
> > > for the requirement is that PyGTK installs the pygtk-codegen script for
> > > generating most of the function wrappers.
> > 
> > As long as the bindings build can be disabled, I'm all for having pygtk
> > as a requirement.
> 
> Hmm .. if it would be possible to build the bindings without pygtk that
> would be the best. But if it's just not doable or too much work I guess
> we can live with depending on pygtk in this case.
> 
> Having a pygtk dependency for python bindings for libmrproject is pretty
> bad, since that involves an extra dependency on. Gtk+, ATK, Pango, X.
> 
> For example someone wanting to write a python-cgi script that uses a
> mrproject file in the back for something would have to install X and
> friends.

Yeah, all good points.

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

The advantage of this route is that if a systematic bug is discovered in
the code generating stuff, it can be fixed for almost everything in
codegen and that filters through in the next build.

I sympathise with the list of added requirements (although until you
listed them, I had not consciously realised how numerous they were).
Thinking about this some more, I might set things up so that you need
PyGTK to build from CVS only. Then the generated mrproject.c file can be
included in the dist tarball and _if_ somebody building from the tarball
has pygtk-codegen installed, we will conditionally rebuild mrproject.c
at build time. That seems a reasonable balance between checking in
generated sources and requiring something hard to make the build work.

Any obvious problems with this that anybody can see?

Regards,
Malcolm

-- 
No one is listening until you make a mistake.