|
From: | Jean Abou Samra |
Subject: | Re: [PoC] EXPERIMENTAL binaries of LilyPond 2.22.1 |
Date: | Sat, 15 May 2021 17:30:51 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 |
Le 15/05/2021 à 17:02, Jonas Hahnfeld a écrit :
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 :64-bit, right? This sounds nifty.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)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...
Understood. At any rate, any type of Mac OS 64-bit compilation gets us out of the Catalina morass. As far as I understand, what is needed at this point is: - improving Guile 2 support, - setting up a release team with people running GNU/Linux and Mac OS, or some kind of remote builder for Mac OS, to do the regular releases. Is this correct?
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
Thanks!
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.
Okay.
> 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.
Okay. Cheers, Jean
[Prev in Thread] | Current Thread | [Next in Thread] |