Re: Issue 2758. ly_module_lookup caused deprecation warnings with Guile V2.06. (issue 6458159)

[ianhulin44]

On 2012/09/08 09:13:17, dak wrote:
> On 2012/09/06 23:24:04, Ian Hulin (gmail) wrote:
> > On 2012/09/06 18:07:53, dak wrote:
> >
> > > When we go Guilev2, we don't want to search for all the backward
> > compatibility.
> > > So I'd say you use something like
> > >
> > > #if GUILEV1
> > >
> > > for splicing in the compatibility stuff, and define it as either 0
or 1 in
> > > lily-guile.hh, depending on the conditional you use here.
> > >
> > > Once we decide to go Guilev2 proper, we rip out the definition in
> > lily-guile.hh,
> > > and all uses of GUILEV1 will bomb out.
> > >
> > > That way we at least don't overlook the compatibility crutches.
> >
> > Nice idea, but probably better to define the macro in
guile-compatibility.hh,
> > which lily-guile.hh pulls in. I can then use as complementary
GUILEV2 macro
> > which will be needed for the Guile V2-specific bits in main.cc.

> Sounds like a plan.  I guess neither of us are fond of the old use of
> undocumented (and by now deprecated, as opposed to module-variable)
internal
> Guile functions.  We disagree about what to replace it with: I would
use the
> Scheme functions, saving the need for distinguishing Guilev1/Guilev2,
you want
> to use the C functions and keep different versions for Guilev1 and
Guilev2.

> If you implement the compatibility in the manner I propose (with your
> modification), we are sure that the ugly code does not stick around
after going
> Guilev2-only.  So that's ok with me as well.  Having the GUILEv1 macro
> temporarily defined will also help the transition elsewhere, and we
should
> probably also use a similar strategy at the Scheme level.

I'll upload another patch-set.

Unfortunately things may slow down at my end again as I'm back teaching
and starting another round of mind-bending meds.

Cheers,
Ian

http://codereview.appspot.com/6458159/