Re: Some wild considerations and a question

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

> Closing words: In general, a replacement for GUB is not something to
> be discussed in length on -user. This must happen in a proper thread
> on the -devel list, and hopefully with more technical content than
> just the statement of "we need something better".

-- 
David Kastrup