Re: Latest changes in G-Wrap

[Ludovic Courtès]

Hi G-Wrappers!

Andy Wingo <address@hidden> writes:

> (We do have a mailing list; why not use it?)

Because it's hard to get an answer from Andreas this way.  Sorry if that
sounds harsh, but the mailing list archive does not contradict this.

> On Mon, 2006-10-09 at 18:19 +0200, Ludovic Courtès wrote:
>> >> * Why remove `AC_PREREQ' from `configure.ac'?  Such things can help make
>> >>   software more perennial IMO. (This is from `g-wrap--dev--0--patch-25'
>> >>   it seems.)
>> >>
>> > I didn't do this on purpose - this must have been accidential.
>> 
>> Ok, so maybe we should revery this one.
>
> No, there's no reason to have it require 2.60; also that version is not
> in any version of ubuntu, which makes it impossible for me to hack on
> g-wrap. Also, the version of autoconf is already checked for in
> autogen.sh.
>
> See my attached bundle for this fix, and some other build fixes.

Having `autogen.sh' check this is nice, but `AC_PREREQ' is the canonical
way to express such dependencies.  So I think we should keep both.

Now, if 2.59 is enough, I don't mind having `AC_PREREQ(2.59)', of
course.

>> >> * Why add the awful `module-use!' statement at the end of /g-wrap.scm?
>> >>   When were they needed?  1.9.6 did not have this, right?  So how can
>> >>   someone have come to rely on this?
>> >>
>> > I split out some generics into `(g-wrap c-codegen)' and `(g-wrap
>> > scm-codegen)' which previously resided in (g-wrap); perhaps this
>> > should be reverted so one can do away with the `module-use!' and not
>> > break guile-gnome.
>> 
>> Well...  On one hand, I understand that all this can be very painful for
>> `guile-gnome'.  OTOH, this logical separation makes sense and probably
>> helps understand G-Wrap as one discovers it.
>
> It probably makes sense, yes; but quite a bit of pain for me. It means
> you won't be able to build older guile-gnome with newer g-wrap. (When do
> I get a stable version?)

That's the one question I've been asking for some time: When do we get a
stable version?  Well, I'm not the maintainer you know, I'm just trying
to help.  ;-)

>> there are (AFAIK) only a handful
>> of users of G-Wrap 1.9 at this point.  So maybe it'd be reasonable to
>> propagate such a change in 2.0.
>
> I'd be OK with this, if there's sufficient warning :)

Ok, so let's do it, unless someone else finds a compelling argument.

> I'm attaching three bundles.
>
> The first one has some build fixes that you might already have, to allow
> older autoconf and out-of-tree libffi.

I believe this is mostly already part of Andreas' branch.

> The second one has a warning fix for some char* code generation; it's
> adequately commented.

Yes, this is in Andreas' branch, too.

> The third is more invasive. It removes the need for generics to be
> placed in the root module, for guile, while preserving compatibility.

I don't get this one.  Could you please provide more context and
rationale?  :-)

Specifically:

> #     * guile/g-wrap/guile.scm (module-public-interface): Make sure that
> #     using (g-wrap guile) also uses (g-wrap c-codegen), as it used to.
> #     This fixes compilation of guile-gnome.
> #     (generate-wrapset-scm): Reindent for spaces instead of tabs. If
> #     this module had generics, make our public interface export the
> #     generics as well.

Is this a guile-gnome-tailored arrangement?  If so, then perhaps we
should explicitly mention somewhere that G-Wrap is a tool *for*
guile-gnome, not a tool that seeks generality.

I mean: of course, we don't want to make guile-gnome's life harder for
no reason.  But we should also decide on G-Wrap's goals: if we can make
it generic enough (and it's already doing good in that respect, better
than SWIG, needless to say), then we should somehow "set a direction"
and avoid being too application-specific.

> #     * guile/g-wrap/guile-runtime.c
> #     (gw_guile_ensure_latent_generics_hash)
> #     (gw_generics_module_binder_proc)
> #     (gw_guile_ensure_generics_module)
> #     (gw_guile_set_generics_module_x)
> #     ("%gw:procedure-to-method-public!"): Rework so that we don't munge
> #     the root module or the scm module. Instead our generics are
> #     deposited into a module of the user's choosing, defaulting to a
> #     submodule named %generics.
> #     
> #     * guile/g-wrap/guile-runtime.c
> #     * guile/g-wrap/guile-runtime.h
> #     (gw_guile_set_generics_module_x): New public
> #     API.

I don't get those either.

> Any chance these could get in your repo?

Personally, I'd be glad if Andreas could provide use his views on the
topic.  I'd like to see more consistency and clear rationale in the
changes that we make, and I'd like them to follow *some* vision of what
G-Wrap should be.  In particular, clarify whether G-Wrap is just
guile-gnome's and Gnumeric's tool (I say "just", but I know it's already
a lot), or whether it's trying to be a generic replacement for SWIG, at
least for Guile-targeting programs.  I'm hoping for the latter, and I
believe that's how it started.

Thanks,
Ludovic.