Re: Build system

[muppet <scott asofyet org>]

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
> applications:
>
> 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