Re: Build system

[Emmanuele Bassi <ebassi gmail com>]

Hi muppet,

On Sun, 2006-03-12 at 18:37 -0500, muppet wrote:
> Yes, a timely response.  Ahem.

No problem - as you can see, I didn't even began writing (much) code.

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

I've always thought, with a bit of shame for this thought, that
ExtUtils::Depends was a bit broken, even as a perl-ish solution to
dependency issues.

Finally, after much tinkering and thinking about the build system, I've
come to the enlightened conclusion that ExtUtils::Depends simply sucks,
and should be scrapped entirely.  I realise that we would be breaking
things, and so a parallel installation should be in order; but the
blatant disregard of the world outside the Perl bindings for a module
shouldn't be condoned or tolerated anymore: the gtk2-perl bindings
should be as easy to integrate for a C developer as they are for the
Perl developer.  We have the technology.

[3. auto-generated stuff]

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

Yep, you are right.  That was a knee-jerk reaction of mine, mostly due
to the frustration, and after cooling down, I really don't see the need
for a code generator for the common case; nevertheless, the
"inside-an-application" scenario requires something *like* a code
generator, since we wouldn't have access to either all the Perl goodies
or the introspection data of a library.  So, an hypothetical
gperl-codegen would be have just a limited usage and scope, and could
really be shipped as a side project.

> > 4. I don't remember point four, but it'll come to mind eventually.
>
> I think it was "... PROFIT!!!!!111!!1one"  :-)

Yep, something like that. :-D

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

The weirdest and messiest parts are:

  1. missing bits - I can't find the bindings shared objects or the
     header files without using ExtUtils::Depends into a script
  2. Perl non-inehritance - I can't automagically make a Gedit::Window
     inherit from Gtk2::Window, even though GeditWindow is a GtkWindow
     at C level - this is because I can't get the typemaps from the Gtk2
     package; so I have to resort to a series of @ISA hacks which really
     break down maintainability
  3. kludginess and non-integration: making everything work inside an
     auto-tools based project Brings Pain and Misery Upon The Developer

There's no "Silver Bullet Solution" to these issues.  A viable road map
might be creating a build system using on Module::Build, which exports
everything inside a pkg-config file, allowing us to integrate all the
stuff we are already doing inside MakeHelper and ParseXSDoc; make Glib
depend on it, and then use it throughout all the modules.  Of course,
I'm not sure it's the best option - and anyone is more than welcome to
propose an alternative solution and point me in the right direction; but
I feel that pkg-config, auto-tools integration in the tool chain and
standard locations for the build stuff is probably the right way to go.

As soon as I'm able to reclaim some spare time (next month, probably),
it'll be at the top of my list.

Ciao,
 Emmanuele.

-- 
Emmanuele Bassi - <ebassi gmail com>
Log: http://log.emmanuelebassi.net