Re: Can no longer build.
Jonas Hahnfeld writes: > Am Samstag, den 09.11.2019, 13:23 +0100 schrieb David Kastrup: >> Jonas Hahnfeld via Discussions on LilyPond >> development writes: >> > Am Samstag, den 09.11.2019, 12:55 +0100 schrieb David Kastrup: >> > > Jonas Hahnfeld 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 >> > 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
Re: Can no longer build.
Am Samstag, den 09.11.2019, 13:23 +0100 schrieb David Kastrup: > Jonas Hahnfeld via Discussions on LilyPond > development writes: > > Am Samstag, den 09.11.2019, 12:55 +0100 schrieb David Kastrup: > > > Jonas Hahnfeld 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 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? 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). Jonas signature.asc Description: This is a digitally signed message part
Re: Can no longer build.
Jonas Hahnfeld via Discussions on LilyPond development writes: > Am Samstag, den 09.11.2019, 12:55 +0100 schrieb David Kastrup: >> Jonas Hahnfeld writes: >> > >> > AFAICS configure requires a guile executable between versions >> > 1.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 a >> Guile-2executable. It's the Guile-1.8 development libraries that >> are neededfor compilation into the LilyPond binary, but the scripts >> are fine usinglater binaries of Guile. > > That is $ git log -p -n1 e9ae1cb3b093498ccb9d5f7348c755a3243bbccc -- > configure.accommit e9ae1cb3b093498ccb9d5f7348c755a3243bbcccAuthor: > Thomas Morley Date: Sun Mar 19 14:29:04 2017 > +0100 > Issue 5108 Let configure find all needed files with guile-2.2 in > configure.ac Adds support for STEPMAKE_GUILE Update guile-versions for > STEPMAKE_GUILE and STEPMAKE_GUILE_DEVEL in aclocal.m4 update the list > to search for guile-config Many thanks to Antonio Ospite > diff --git a/configure.ac b/configure.acindex d77ea15881..8f2f61abf8 > 100644--- 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) else > STEPMAKE_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 # perl > for help2man and for mf2pt1.pl STEPMAKE_PERL(REQUIRED) > but before this commit, it would just always require Guile 1.8.2 to > 1.9.0. I've no experience with using guile-2.0 or guile-2.2 for the > scripts, but if you post a patch I can give it a try (Arch Linux > bundles all three versions). > Just wondering if it's wise to use a different version of Guile for > the scripts than the libraries... For a cross environment like GUB it seems like excessive work (and possible improvements in Scheme execution speed do not seem performance-relevant). But for stuff intended to run as natively as possible, relying on current and maintained executables tends to be better from a maintenance and security view. -- David Kastrup
Re: Can no longer build.
Am Samstag, den 09.11.2019, 12:55 +0100 schrieb David Kastrup: > Jonas Hahnfeld writes: > > Am Freitag, den 08.11.2019, 22:21 +0100 schrieb David Kastrup: > > > Thomas Morley writes: > > > > Am Fr., 8. Nov. 2019 um 16:34 Uhr schrieb David Kastrup : > > > > > I got it now. I used to do./configure --enable-checking > > > > > GUILE_CONFIG=/usr/local/tmp/guile-1.8/bin/guile-configbut that > > > > > appears to mess up the setting of GUILE, so I need to > > > > > do./configure--enable-checkingGUILE_CONFIG=/usr/local/tmp/guile-1.8/bin/guile-configGUILE=/usr/bin/guileApparently > > > > > using GUILE_CONFIG precludes or sabotages the checks for GUILE ? > > > > > > > > I made the experience that I need to setGUILE_CONFIG=... *and*GUILE=... > > > > if I want a build which uses a notsystem-wide installedguile-version. > > > > > > But I have a system-wide installed guile version at /usr/bin/guile.It's a > > > Guile-2.0 but that's fine for scripts. So there really isnogood reason > > > that it isn't found. > > > > AFAICS configure requires a guile executable between versions 1.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 a > Guile-2executable. It's the Guile-1.8 development libraries that are > neededfor compilation into the LilyPond binary, but the scripts are fine > usinglater binaries of Guile. That is $ git log -p -n1 e9ae1cb3b093498ccb9d5f7348c755a3243bbccc -- configure.accommit e9ae1cb3b093498ccb9d5f7348c755a3243bbcccAuthor: Thomas Morley Date: Sun Mar 19 14:29:04 2017 +0100 Issue 5108 Let configure find all needed files with guile-2.2in configure.acAdds support for STEPMAKE_GUILEUpdate guile-versions for STEPMAKE_GUILE and STEPMAKE_GUILE_DEVELin aclocal.m4update the list to search for guile-configMany thanks to Antonio Ospite diff --git a/configure.ac b/configure.acindex d77ea15881..8f2f61abf8 100644--- 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) else STEPMAKE_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 # perl for help2man and for mf2pt1.pl STEPMAKE_PERL(REQUIRED) but before this commit, it would just always require Guile 1.8.2 to 1.9.0. I've no experience with using guile-2.0 or guile-2.2 for the scripts, but if you post a patch I can give it a try (Arch Linux bundles all three versions). Just wondering if it's wise to use a different version of Guile for the scripts than the libraries... Jonas signature.asc Description: This is a digitally signed message part
Re: Can no longer build.
Jonas Hahnfeld writes: > Am Freitag, den 08.11.2019, 22:21 +0100 schrieb David Kastrup: >> Thomas Morley writes: >> > Am Fr., 8. Nov. 2019 um 16:34 Uhr schrieb David Kastrup : >> > > I got it now. I used to do >> > > ./configure --enable-checking >> > > GUILE_CONFIG=/usr/local/tmp/guile-1.8/bin/guile-config >> > > but that appears to mess up the setting of GUILE, so I need to do >> > > ./configure >> > > --enable-checkingGUILE_CONFIG=/usr/local/tmp/guile-1.8/bin/guile-configGUILE=/usr/bin/guile >> > > Apparently using GUILE_CONFIG precludes or sabotages the checks for >> > > GUILE ? >> > >> > I made the experience that I need to set >> > GUILE_CONFIG=... *and*GUILE=... if I want a build which uses a not >> > system-wide installedguile-version. >> >> But I have a system-wide installed guile version at /usr/bin/guile >> .It's a Guile-2.0 but that's fine for scripts. So there really is >> nogood reason that it isn't found. > > AFAICS configure requires a guile executable between versions 1.8.2 to > 1.9.0 (see configure.ac, line 309), unless you pass --enable-guile2 > which is off by default. That would seem a mistake. LilyPond works perfectly well with a Guile-2 executable. It's the Guile-1.8 development libraries that are needed for compilation into the LilyPond binary, but the scripts are fine using later binaries of Guile. -- David Kastrup
Re: Can no longer build.
Am Freitag, den 08.11.2019, 22:21 +0100 schrieb David Kastrup: > Thomas Morley writes: > > Am Fr., 8. Nov. 2019 um 16:34 Uhr schrieb David Kastrup : > > > I got it now. I used to do > > > ./configure --enable-checking > > > GUILE_CONFIG=/usr/local/tmp/guile-1.8/bin/guile-config > > > but that appears to mess up the setting of GUILE, so I need to do > > > ./configure > > > --enable-checkingGUILE_CONFIG=/usr/local/tmp/guile-1.8/bin/guile-configGUILE=/usr/bin/guile > > > Apparently using GUILE_CONFIG precludes or sabotages the checks for GUILE > > > ? > > > > I made the experience that I need to set GUILE_CONFIG=... *and*GUILE=... if > > I want a build which uses a not system-wide installedguile-version. > > But I have a system-wide installed guile version at /usr/bin/guile .It's a > Guile-2.0 but that's fine for scripts. So there really is nogood reason that > it isn't found. AFAICS configure requires a guile executable between versions 1.8.2 to 1.9.0 (see configure.ac, line 309), unless you pass --enable-guile2 which is off by default. Jonas signature.asc Description: This is a digitally signed message part
Re: Can no longer build.
Thomas Morley writes: > Am Fr., 8. Nov. 2019 um 16:34 Uhr schrieb David Kastrup : >> >> I got it now. I used to do >> >> ./configure --enable-checking >> GUILE_CONFIG=/usr/local/tmp/guile-1.8/bin/guile-config >> >> but that appears to mess up the setting of GUILE, so I need to do >> >> ./configure --enable-checking >> GUILE_CONFIG=/usr/local/tmp/guile-1.8/bin/guile-config >> GUILE=/usr/bin/guile >> >> Apparently using GUILE_CONFIG precludes or sabotages the checks for GUILE ? > > > I made the experience that I need to set GUILE_CONFIG=... *and* > GUILE=... if I want a build which uses a not system-wide installed > guile-version. But I have a system-wide installed guile version at /usr/bin/guile . It's a Guile-2.0 but that's fine for scripts. So there really is no good reason that it isn't found. For the Guile compiled into LilyPond, of course setting GUILE_CONFIG is wanted (if the correct guile-config is not in the PATH). -- David Kastrup
Re: Can no longer build.
Am Fr., 8. Nov. 2019 um 16:34 Uhr schrieb David Kastrup : > > Dan Eble writes: > > > On Nov 8, 2019, at 09:11, David Kastrup wrote: > >> > >> So how come my lilypond-invoke-editor script starts with > >> > >> "echo no not found -s" > >> > >> as its interpreter? Note that some underlying problem might not be new: > > > > 1. What does "grep -w GUILE config.make" tell you? (Will be the same, I > > guess.) > > 2. Does reconfiguring yield a different before this commit? > > > > commit ad3effb7569fcd7182aa7b491b1d44fca3696c38 > > Author: Jonas Hahnfeld > > Date: Tue Oct 15 22:00:02 2019 +0200 > > > > Check additional names for guile-config > > > > On Arch Linux, the executable is called guile-config1.8 instead of > > guile-config-1.8 or guile-1.8-config. > > I got it now. I used to do > > ./configure --enable-checking > GUILE_CONFIG=/usr/local/tmp/guile-1.8/bin/guile-config > > but that appears to mess up the setting of GUILE, so I need to do > > ./configure --enable-checking > GUILE_CONFIG=/usr/local/tmp/guile-1.8/bin/guile-config GUILE=/usr/bin/guile > > Apparently using GUILE_CONFIG precludes or sabotages the checks for GUILE ? I made the experience that I need to set GUILE_CONFIG=... *and* GUILE=... if I want a build which uses a not system-wide installed guile-version. Opposed to what you once wrote: "It doesn't matter where you install Guile as long as you specify GUILE_CONFIG=/usr/local/tmp/guile-1.8/bin/guile-config (or similar, depending on where you installed your Guile-1.8) as one argument to either ./autogen.sh or ./configure since guile-config has the installation path baked in and is used for providing all path-dependent options for compilation and linking." Though, I've no clue whether it _should_ work with solely setting GUILE_CONFIG=... Cheers, Harm
Re: Can no longer build.
Dan Eble writes: > On Nov 8, 2019, at 09:11, David Kastrup wrote: >> >> So how come my lilypond-invoke-editor script starts with >> >> "echo no not found -s" >> >> as its interpreter? Note that some underlying problem might not be new: > > 1. What does "grep -w GUILE config.make" tell you? (Will be the same, I > guess.) > 2. Does reconfiguring yield a different before this commit? > > commit ad3effb7569fcd7182aa7b491b1d44fca3696c38 > Author: Jonas Hahnfeld > Date: Tue Oct 15 22:00:02 2019 +0200 > > Check additional names for guile-config > > On Arch Linux, the executable is called guile-config1.8 instead of > guile-config-1.8 or guile-1.8-config. I got it now. I used to do ./configure --enable-checking GUILE_CONFIG=/usr/local/tmp/guile-1.8/bin/guile-config but that appears to mess up the setting of GUILE, so I need to do ./configure --enable-checking GUILE_CONFIG=/usr/local/tmp/guile-1.8/bin/guile-config GUILE=/usr/bin/guile Apparently using GUILE_CONFIG precludes or sabotages the checks for GUILE ? -- David Kastrup
Re: Can no longer build.
On Nov 8, 2019, at 09:11, David Kastrup wrote: > > So how come my lilypond-invoke-editor script starts with > > "echo no not found -s" > > as its interpreter? Note that some underlying problem might not be new: 1. What does "grep -w GUILE config.make" tell you? (Will be the same, I guess.) 2. Does reconfiguring yield a different before this commit? commit ad3effb7569fcd7182aa7b491b1d44fca3696c38 Author: Jonas Hahnfeld Date: Tue Oct 15 22:00:02 2019 +0200 Check additional names for guile-config On Arch Linux, the executable is called guile-config1.8 instead of guile-config-1.8 or guile-1.8-config. — Dan
Can no longer build.
I have the following problem: dak@lola:/usr/local/tmp/lilypond$ CPU_COUNT=9 make -j9 Making scripts/out/lilypond-invoke-editor.1 help2man: can't get `--help' info from out/lilypond-invoke-editor Try `--no-discard-stderr' if option outputs to stderr make[1]: *** [/usr/local/tmp/lilypond/stepmake/stepmake/help2man-rules.make:27: out/lilypond-invoke-editor.1] Error 127 make[1]: *** Deleting file 'out/lilypond-invoke-editor.1' make: *** [/usr/local/tmp/lilypond/stepmake/stepmake/generic-targets.make:6: all] Error 2 dak@lola:/usr/local/tmp/lilypond$ scripts/out/lilypond-invoke-editor --help bash: scripts/out/lilypond-invoke-editor: -: bad interpreter: No such file or directory dak@lola:/usr/local/tmp/lilypond$ head scripts/out/lilypond-invoke-editor #!- echo no not found -s !# lilypond-invoke-editor.scm -- Invoke an editor in file:line:column mode Copyright (C) 2005--2019 Jan Nieuwenhuizen This file is part of LilyPond, the GNU music typesetter. LilyPond is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by So how come my lilypond-invoke-editor script starts with "echo no not found -s" as its interpreter? Note that some underlying problem might not be new: I have frequently had to start make a second time here (I considered it a timing problem): it may just be that previously the failure left an empty file that allowed the next iteration to complete. -- David Kastrup