lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Can no longer build.


From: David Kastrup
Subject: Re: Can no longer build.
Date: Sat, 09 Nov 2019 15:08:23 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Jonas Hahnfeld <address@hidden> writes:

> Am Samstag, den 09.11.2019, 13:23 +0100 schrieb David Kastrup:
>> Jonas Hahnfeld via Discussions on LilyPond development<address@hidden> 
>> writes:
>> > Am Samstag, den 09.11.2019, 12:55 +0100 schrieb David Kastrup:
>> > > Jonas Hahnfeld <address@hidden> writes:
>> > > > AFAICS configure requires a guile executable between
>> > > > versions1.8.2 to1.9.0 (see configure.ac, line 309), unless you
>> > > > pass--enable-guile2which is off by default.
>> > > 
>> > > That would seem a mistake.  LilyPond works perfectly well with
>> > > aGuile-2executable.  It's the Guile-1.8 development libraries
>> > > thatare neededfor compilation into the LilyPond binary, but the
>> > > scriptsare fine usinglater binaries of Guile.
>> > 
>> > That is $ git log -p -n1 e9ae1cb3b093498ccb9d5f7348c755a3243bbccc
>> > --configure.accommit
>> > e9ae1cb3b093498ccb9d5f7348c755a3243bbcccAuthor:Thomas Morley
>> > <address@hidden>Date: Sun Mar 19 14:29:04 2017+0100
>> > Issue 5108 Let configure find all needed files with guile-2.2
>> > inconfigure.ac Adds support for STEPMAKE_GUILE Update
>> > guile-versions forSTEPMAKE_GUILE and STEPMAKE_GUILE_DEVEL in
>> > aclocal.m4 update the listto search for guile-config Many thanks
>> > to Antonio Ospitediff --git a/configure.ac b/configure.acindex
>> > d77ea15881..8f2f61abf8100644--- a/configure.ac+++ b/configure.ac@@
>> > -181,7 +181,7 @@STEPMAKE_TEXMF(REQUIRED)
>> > STEPMAKE_TEXMF_DIRS(REQUIRED) if test"$GUILEv2" = "yes" then-
>> > STEPMAKE_GUILE_DEVEL(REQUIRED, 2.0.7,
>> > 2.2.0)+STEPMAKE_GUILE_DEVEL(REQUIRED, 2.0.7, 2.3.0)
>> > elseSTEPMAKE_GUILE_DEVEL(REQUIRED, 1.8.2, 1.9.0) fi@@ -267,7
>> > +267,12 @@STEPMAKE_FREETYPE2(freetype2, REQUIRED, 2.1.10)
>> > STEPMAKE_WINDOWS #guile executable for some
>> > scripts-STEPMAKE_GUILE(OPTIONAL, 1.8.2,1.9.0)+if test "$GUILEv2" =
>> > "yes"+then+ STEPMAKE_GUILE(OPTIONAL,2.0.7, 2.3.0)+else+
>> > STEPMAKE_GUILE(OPTIONAL, 1.8.2, 1.9.0)+fi # perlfor help2man and
>> > for mf2pt1.pl STEPMAKE_PERL(REQUIRED)but before this commit, it
>> > would just always require Guile 1.8.2 to1.9.0. I've no experience
>> > with using guile-2.0 or guile-2.2 for thescripts, but if you post
>> > a patch I can give it a try (Arch Linuxbundles all three
>> > versions).Just wondering if it's wise to use a different version
>> > of Guile forthe scripts than the libraries...
>> 
>> For a cross environment like GUB it seems like excessive work
>> (andpossible improvements in Scheme execution speed do not
>> seemperformance-relevant).
>> But for stuff intended to run as natively as possible, relying
>> oncurrent and maintained executables tends to be better from a
>> maintenanceand security view.
>
> So I think you're saying that using two versions of Guile for the same
> build is fine, right?

It's not really "two versions".  One is the runtime environment to be
integrated into the application, the other is a standalone interpreter.
They are really independent entities.  While Debian allows the runtime
libraries of more than one Guile version to be installed in parallel,
the respective developing packages (that have their compilation/linking
options provided by guile-config) are conflicting.  The standalone
interpreters can be installed in parallel though, I think.  Not
completely sure though.

> I fully agree that a maintained version is better than one from 2010.
> Eventually, it would be great if LilyPond didn't rely on Guile 1.8
> forever, but I have no clue as to how much work that would mean (and
> I'm not interested to spend time until we're done with the Python
> stuff).

It's not just that it implies a solid bunch of work, it's also that with
the current architecture of both LilyPond and Guile, it's a really bad
performance hit for comparatively little gain.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]