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/ _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
