Re: [PoC] EXPERIMENTAL binaries of LilyPond 2.22.1

[Jonas Hahnfeld]

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