[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Some wild considerations and a question
From: |
David Kastrup |
Subject: |
Re: Some wild considerations and a question |
Date: |
Tue, 20 Oct 2020 19:26:07 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
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. There were a few sort-of discussions/attempts on the
lilypond-devel list to clear things up without conclusive results.
--
David Kastrup
- Re: Some wild considerations and a question, (continued)
- Re: Some wild considerations and a question, Andrew Bernard, 2020/10/19
- Re: Some wild considerations and a question, Thomas Morley, 2020/10/19
- Re: Some wild considerations and a question, Thomas Morley, 2020/10/19
- Re: Some wild considerations and a question, Thomas Morley, 2020/10/19
- Re: Some wild considerations and a question, David Kastrup, 2020/10/19
- Re: Some wild considerations and a question, Jean Abou Samra, 2020/10/20
- Re: Some wild considerations and a question, Jonas Hahnfeld, 2020/10/20
- Re: Some wild considerations and a question, David Kastrup, 2020/10/20
- Re: Some wild considerations and a question, Jonas Hahnfeld, 2020/10/20
- Re: Some wild considerations and a question,
David Kastrup <=
- Re: Some wild considerations and a question, Karlin High, 2020/10/20
- Re: Some wild considerations and a question, Jonas Hahnfeld, 2020/10/20