Re: Inline, XS, and Gtk2-perl

[Goran Thyni <goran kirra net>]

Ross,

this has been discussed many times before,
check the archives.

I'm no longer the project manager so the decision is not mine
but as the individual who has probably made the largest contribution
to the gtk2-perl code base I can say this much:
Without the use of Inline there probably would not be a workable
gtk2-perl at all.

gtk+ is a large library to cover.
in the old gtk-perl the choice was to
autogenerate XS code - leading to lots of
bugs and a very complicated build systems.

I choose to start writing test and hand coding the
needed functionality with Inline.
Coding with Inline is faster and easier than XS
especially if you need to call some functions from
both perl and C.

Besides Inline is only used for development not by
an installed runtime. Debian already has the patch
to inline released and Ingy has promised a new release
soon.

There are still some functionality missing and surely quiet
a few bugs in there. Fixing that should IMHO be have priority 
over spending time making the library harder the maintain for 
some political reason. Please, please.

happy hacking,
/göran


On Tue, Mar 25, 2003 at 10:56:41AM -0500, Ross McFarland wrote:
> over the past 2-3 years or so my programming time (both at work and home) is
> split around 50/50 between C and PERL, more than that most of the projects i
> work on are comprised of C libraries that are brought into PERL using XS. i
> also do a decent amount of work with Gtk-perl creating GUI apps that use the
> above.
>
> a few days ago i went to take a look at gtk2 and gtk2-perl with the intention
> of contributing if i found anything i was interested at looking into. i
> checked out a clean cvs copy and set out looking at things. i was a little
> more than surprised to see that it was using Inline.
>
> i've used Inline in the past and found it to be advantageous in situations
> where you want to do something that requires horsepower in a reasonable amount
> of time where there's a function or so of c code you want to get at from perl.
> however, i'm my past experience it totally seemed to fall apart when i went to
> use it for anything more ambitious.
>
> after looking over the gtk2-perl code Inline seems to have fallen apart here
> and been propped back up by the likes of fast-compile and compile-widgets not
> to mention the patch to Inline.
>
> hopefully i'm not too far out of line in saying all this, it's not meant as an
> attack, but your gonna end up putting as much if not more work into the build
> system and workarounds for the fact that your using inline than you will the
> actual code. especially once you start trying to compile all all kinds of
> systems and out of the ordinary configurations.
>
> i'll give you that there's a little bit of a learning curve to XS, but you'll
> put more effort into shoehorning Inline than it would have ever taken to get
> past the learning curve of XS. beyond that anyone that comes in with the
> intention to help will have the leaning curve of the Inline hacks required
> even if they are already proficient in XS and related issues (like myself.)
>
> one of the main features of Inline is that the code is right in the perl
> module where you use it, with the code in separate files you've lost that and
> with it much of the value of Inline.
>
> another issue is that if build breaks (as it did for me) then no one will have
> a clue what to do. with normal Inline or XS builds someone with some expirence
> will be able to look into what went wrong. if your build system requires all
> of these helper scripts and such they'll (i'll) have no clue where to look
> without an in depth study of things.
>
> granted it would be a shame to lose the efforts that have been put into the
> build and work arounds thus far, but most of the design decisions and
> organization will still hold, so it's not like all of the work would be lost.
>
> i would be willing to help, if you all wish, in the transistion should you all
> decide to do so.
>
> -rm