guile-gtk-general
[Top][All Lists]
Advanced

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

Re: g-wrap parallel installability part deux


From: Andreas Rottmann
Subject: Re: g-wrap parallel installability part deux
Date: Wed, 29 Sep 2004 11:03:34 +0200
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

Andy Wingo <address@hidden> writes:

> Yo Andreas,
>
> On Sun, 2004-09-26 at 15:25 +0200, Andreas Rottmann wrote:
>> David Pirotte <address@hidden> writes:
>> 
>> > here it is
>> >
>> This looks a bit like you having installed the old G-Wrap (1.3.4, for
>> instance) somewhere in the %load-path, preceding the new G-Wrap
>
> This is going to become a really common case. I just uninstalled gnucash
> so that I could install guile-gnome. It's going to suck a lot to say
> "Install guile-gnome, but, er, not if you have gnucash..."
>
Well, GnuCash depends on the G-Wrap .scm modules only at build time,
so it should be no problem overwriting the old g-wrap module (assuming
that people don't want to rebuild gnucash).

> Changing gnucash isn't looking exciting -- I don't see them releasing a
> fix anytime soon, what with the gtk2 work and all. Seems we're stuck
> with the old g-wrap for a while. Any parallel-install situation sounds
> exceedingly painful when the modules have the same name. Changing guile-
> gnome, etc to use a new g-wrap name sounds really crappy too, prone to
> introduce bugs, not to mention changing g-wrap itself.
>
> In light of all of this crappiness, maybe we can kludge again. Include
> the old g-wrap in the new g-wrap distro as (g-wrap 1.3.4), and then 
>    (module-use! (resolve-interface '(g-wrap))
>                 (resolve-interface '(g-wrap 1.3.4)))
> Since all of the old routines and datatypes have a gw: prefix, they
> (ironically) don't conflict with the current g-wrap. We make sure the
> latest release of gnucash builds with that setup. Then we link
> $(installdir)/g-wrap/$oldfile.scm to $(installdir)/g-
> wrap/old/$oldfile.scm.
>
Why this linking?

> The only collision will be (g-wrap enumeration), which can be solved by
> a similar hack if necessary.
>
> Of course we'll have to detect an existing g-wrap 1.3.4 at configure
> time, and error out if we're not overwriting the old installation.
>
> I think it's the route of least pain. What do you think, Andreas? Rob?
> If you can get this working within a week or so, I'd wait to release
> guile-gnome -- I'd really like to avoid answering this question again ;)
>
This indeed seems like a solution to offer backwards-compatibility
(though being quite heavyweight, since we'd ship the whole old G-Wrap
code, including runtime). I've started hacking a bit on a
compatibility layer, which would allow to share the runtime, but that
isn't going to be in a state where it can be used to build GnuCash
soon. I'll try and keep you updated on my progress -- I think it
should be possible within a week.

Regards,
-- 
Andreas Rottmann         | address@hidden      | address@hidden | address@hidden
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

To iterate is human; to recurse, divine.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]