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 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.
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
PATCHES - Countdown for November 9th
Hello, Here is the current patch countdown list. The next countdown will be on November 11th. A quick synopsis of all patches currently in the review process can be found here: http://philholmes.net/lilypond/allura/ Push: 5595 Fix nonportable "echo -e" - Dan Eble https://sourceforge.net/p/testlilyissues/issues/5595 http://codereview.appspot.com/575260043 5594 CG: describe new build-verbosity options - Dan Eble https://sourceforge.net/p/testlilyissues/issues/5594 http://codereview.appspot.com/559220043 5592 Make has_interface work with a const Grob * - Jonas Hahnfeld https://sourceforge.net/p/testlilyissues/issues/5592 http://codereview.appspot.com/573210043 Countdown: 5597 musicxml: Use method to get number of Lyric - Jonas Hahnfeld https://sourceforge.net/p/testlilyissues/issues/5597 http://codereview.appspot.com/573230043 5596 "make check" verbosity reduction - Dan Eble https://sourceforge.net/p/testlilyissues/issues/5596 http://codereview.appspot.com/563260043 5217 random results for the merge-rests-engraver regression test - Jonas Hahnfeld https://sourceforge.net/p/testlilyissues/issues/5217 http://codereview.appspot.com/554960043 Review: No patches in Review. New: No New patches at this time. *** Regards, James
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.
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 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
