On 20/07/2013 5:00 PM, Ian Hulin wrote:
On 13/07/13 20:51, Frédéric Bron wrote:
I don't think ./configure should do this automatically, but at
the very least, it should fail when it finds a guile version that
is incompatible with our source code. Can you please open an
issue for it\?
good point, I will do that. Frédéric
Hi Frédéric,
Could you make the Guile-1 compatibility a separate issue from 3382,
which is about tex-info versions?
These are different issues, I don't think there was ever any confusion
about that. Frédéric sent a very clear message to lilypond-bugs about it.
Here's a suggestion: add an --enable-guile-1-compatibilty option
defaulting to #t until the Guile 2 conversion cut-over.
If set to true this sets up the variables you mentioned to be exported
in make.
Once the Guile-2 conversion is complete, we reverse the default for
--enable-guile-1-compatibilty to #f.
aclocal.m4 is the bit which does the configure option parsing,
We'd need new internal variable guile_1_compatibility_b which then
controls declaring
if test "$guile_1_compatibility_b" = yes; then
AC_DEFINE(GUILE_1_COMPATIBILITY)
DEFINES="$DEFINES -DGUILE_1_COMPATIBILITY"
GUILE=" /usr/bin/guile1.8"
GUILE_CONFIG=" /usr/bin/guile1.8-config"
GUILE_TOOLS=" /usr/bin/guile1.8-tools"
fi
This is untested but you get the idea. Model the changes for
aclocal.m4 on the --enable-optimising/($)optimising_b sections.
I haven't looked at what would be needed in the makefiles but this
should give you or Julien a start.
I got started already, see
http://code.google.com/p/lilypond/issues/detail?id=3461. I don't think
that we need a guile-1 compatibility mode right now, since we don't even
support guile-2 yet and dropping guile-1 seems pretty far on the horizon.
--
Julien
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
