Re: Some wild considerations and a question

[Jonas Hahnfeld]

Am Dienstag, den 20.10.2020, 19:26 +0200 schrieb David Kastrup:
> Jonas Hahnfeld <hahnjo@hahnjo.de> writes:
> 
> > Am Dienstag, den 20.10.2020, 18:26 +0200 schrieb David Kastrup:
> > > Jonas Hahnfeld <hahnjo@hahnjo.de> writes:
> > > 
> > > > I don't want to digress into this topic right now (P.S. the reply got
> > > > longer than I initially anticipated), but the scripts have a much
> > > > narrower focus: they mostly compile native binaries (except for
> > > > Windows via mingw) instead of cross-compiling for all targets. In my
> > > > experience from helping with GUB in the past year, that's the main
> > > > source of complexity for usage and maintenance. Moreover, this choice
> > > > also outright prevents 64-bit executables for macOS because of Apple's
> > > > restrictions with regard to their toolchain.
> > > > 
> > > > I'm open to reconsider the choice of sh-scripts, but GUB aims at doing
> > > > just too much (a package manager for building arbitrary packages for
> > > > various targets; where we only do LilyPond to a handful) by using a
> > > > too powerful language and architecture (Python 2 with dynamic
> > > > dependency resolution and generic interfaces to various build
> > > > systems). I think we should learn from that and choose a design that
> > > > avoids the pitfalls.
> > > 
> > > To be fair, GUB could have become a significant part of the GNU compiler
> > > toolchain which would have vindicated its complexity, and at one point
> > > of time it was more or less intended for that.
> > > 
> > > I have not pushed it in that direction since I never was able to get
> > > dependable information about the legal status of our MacOSX port's
> > > toolkit.  While it was clear that the conditions of the 64bit toolkit
> > > precluded its use, the respective conditions for the 32bit kit we used
> > > just were no longer to be found and it was not overly clear just what
> > > version was involved here.  If this would have been replaced by some
> > > OpenDarwin components (but we had nobody to work on that, partly a
> > > hen-and-egg problem), this might have been different.
> > > 
> > > And with the basic "let's not look too closely here" status of the
> > > MacOSX toolkit, extending its reach would have been asking others to
> > > embrace the potential trouble that we were in ourselves.
> > 
> > For my own reading pleasure, do you have links where this was
> > discussed? I mean, I don't see your name in the GUB repo so I'm not
> > sure what "I have not pushed it" means.
> 
> That would not be in the GUB repo but in GNU's internal discussion
> lists.

Are there public archives of that?

> There were a few sort-of discussions/attempts on the
> lilypond-devel list to clear things up without conclusive results.

Do you have pointers to them or roughly know the time frame when they
happened? Most posts in the recent years are from Phil about some
failure or last year's threads about fixing them.

signature.asc
Description: This is a digitally signed message part