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

[dak]

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.

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