Re: Build system

Yes, a timely response.  Ahem.

On Oct 13, 2005, at 4:47 PM, Emmanuele Bassi wrote:

It's been all day I've been trying to add perl bindings to gedit, and I
must say that our build system sucks when dealing with self-contained

1. we simply ignore the existence of the auto-tools - which is not bad,
since they are the spawn of evil as we all know but we also ignore the
existence of pkg-config, which is a bad thing(tm)

2. perl installation scheme sucks bigtime - come on, three possible schemes depending on a variable? where the hell I'm supposed to search for headers, typemaps and whatever if I can't use ExtUtils::Depends?

Would it help to create a different interface for ExtUtils::Depends that works something like pkg-config?

3. we need code auto-generation a-la-pygtk. I can't constantly write XS files in applications where the API changes more frequently than libraries.

The main reason that we don't have such code generation is that, for the most part, there's very little difference between maintaining an API defs file and an overrides file, versus just maintaining hand- written XS. XS is basically a combination of the def and overrides, and gets turned into C code by another process, anyway. In the simplest case, XSUBs are just C prototypes.

But, admittedly, we use a non-standard dialect of POD, and a lot of our own conventions atop of what XS provides, and a lot of our custom code is handling things that XS doesn't know how to do, such as converting between the perl stack and GList or GSList.

If we switched to using a defs file and a generator, we'd have a silly double-generation step, and it would probably make more sense just to have the generator go straight to C code using the perl API. It wouldn't be so bad, really, because we could automate a whole bunch of little things we currently can't.

BUT, that would get us away from the standard Perl tools, which would keep us from getting improvements via xsubpp. It would make our stuff a little harder to integrate with other standard perl extensions.

So, i'm not opposed, but i'm not champing at the bit, either. You'd have to show me something with hands-down wins for most binding projects before i'd back it enthusiastically.

Also, i keep wondering whether gtk+'s introspection stuff will ever materialize. Of course, that may not actually make a difference for the kind of inside-an-application bindings you're talking about...

4. I don't remember point four, but it'll come to mind eventually.

I think it was "... PROFIT!!!!!111!!1one"  :-)

Wrapping up libraries is a no-brainer, thanks to the work done by all the gtk-perl developers; but when it comes to adding a binding support to applications like Epiphany and Gedit, which do not have a nice and clean plugin library, everything becomes very, *very* messy.

What's the messiest part? Dealing with application data structures? Integrating with a non-perl build system? Or just the general not- like-everything-else-ness of it?

In order to making life of plugin writers a little bit easier, we would need at least to address points 1 and 2; adding a pkg-config file to the binding libraries, pointing to the C headers and Perl typemaps would increase the ability to actually use the bindings code outside the library case - and also would make ExtUtils::Depend go away, now that I think of it.

Found: Poop
Someone's dog lost some poop in front of the Studio Theatre. Unfortunately, this article has been slightly damaged since it was neglectfully left on the sidewalk. It is available to its rightful owner (or its owner's rightful owner) if they so desire to come and scrape it off my shoe.
  -- someplace on the internet

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]