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