Re: [PoC] EXPERIMENTAL binaries of LilyPond 2.22.1

[Jean Abou Samra]

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 :
> >   
> > > 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...


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