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.