Am Samstag, dem 15.05.2021 um 16:24 +0200 schrieb Jean Abou Samra: > Le 13/05/2021 à 22:46, Jonas Hahnfeld via Discussions on LilyPond > development a écrit : > > > Before starting: These builds are not official, highly experimental, > > and not meant for "production" installations. They use Guile 2.2 and > > are slower, might not compile all scores or break some advanced > > feature that you might use. The binaries might eat your files or do > > other bad things to your computer - you've been warned! > > > > ... That said, you are of course very welcome to read on: > > > > Hi all, > > > > I revived my efforts from last year to work on a new way to build > > binaries and possibly replacing GUB. For details on the ideas, see > > https://lists.gnu.org/archive/html/lilypond-devel/2020- > > 03/msg00337.html > > and the explanations at https://github.com/hahnjo/lilypond-binaries > > > > After some work, I built binaries from the released sources of > > LilyPond 2.22.1 for > > * Linux (compiled on CentOS 7; tested on Arch, CentOS 8, Ubuntu > > 18.04) > > * FreeBSD (compiled on FreeBSD 11.4; works on FreeBSD 12.2 and 13.0) > > * macOS (compiled on macOS 10.15 (x86_64); hopefully works on Big > > Sur) > > 64-bit, right? This sounds nifty.
Yes, all 64-bit. For macOS, it's x86_64 only and not arm64 (Apple M1). I'm optimistic that it should work with the same approach, but I have to use GitHub Actions because I don't have access to a suitable macOS otherwise, and as far as I know they don't have that type of machines yet... > I didn't comment on Guile 2 because I didn't have an opinion > and I am not competent about that, but I am pretty sure that > a unified release method that gives 64-bit binaries for Mac OS, > plus Windows, is an extremely strong incentive for moving to > Guile 2 permanently. > > [...] > Having `export GUILE_AUTO_COMPILE=1` in my ~/.bash_profile (for > development), I got many warnings, mostly about "possibly unbound > variables", during the first run. That's nothing different from > current master. > > There is, however, one error that appears on every compilation. > I don't have it with my local build. > > ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0 > ;;; or pass the --no-auto-compile argument to disable. > ;;; compiling /home/jean/lilypond-new- > binaries/share/lilypond/2.22.1/scm/ly-syntax-constructors.scm > ;;; WARNING: compilation of /home/jean/lilypond-new- > binaries/share/lilypond/2.22.1/scm/ly-syntax-constructors.scm failed: > ;;; unhandled constant #<fluid 7fcb2efd07f0> > > > I don't have a full history of 2.23 development in mind. > Was this fixed at some point? Yes, that's https://gitlab.com/lilypond/lilypond/-/merge_requests/635/diffs?commit_id=1d7367c3705c54efe38db43d49dfa45295aeb1af > > > > Also I'd like to note that the scripts are a proof-of-concept, > > especially the choice of shell scripts earned me some criticism. > > Where can we read this criticism? I may have misread it, but > I don't see it in the thread you quoted at the beginning of > your message. > The best I could find in public are Han-Wen's concerns in https://lists.gnu.org/archive/html/lilypond-devel/2020-01/msg00416.html "We started out with a set of shell scripts, but they were hard to maintain, so we built GUB. So, to me, Jonas' proposal to have a set of simple compilation scripts is a little funny." (or at least I understand that comment as concern about maintainability of shell scripts; which I generally agree, but at that time I wasn't sure Python is any better when looking at GUB) I did get other comments off-list saying that opting for less expressivity (which was the goal) does not yield better code. > Out of curiosity only, did you consider CMake? > Not sure where CMake fits in there? The problem is not about building a set of sources (the traditional task of build systems), but about orchestrating (pun intended) a couple of those systems to build all needed dependencies. Regular Makefiles were also suggested to me, but I wrote one at my past work to build GCC with all its dependencies, and it was horrible. Jonas
signature.asc
Description: This is a digitally signed message part
