Re: gub targets + binary packages

[Jonas Hahnfeld]

Am Montag, den 07.10.2019, 20:31 +0000 schrieb Carl Sorensen:
> On 10/7/19, 1:47 PM, "Jonas Hahnfeld" <
> address@hidden
> > wrote:
> 
>     Am Montag, den 07.10.2019, 19:23 +0000 schrieb Carl Sorensen:
>     > 
>     > On 10/7/19, 1:10 PM, "Jonas Hahnfeld" <
>     > 
> address@hidden
> 
>     > > wrote:
>     > 
>     >     Am Montag, den 07.10.2019, 17:51 +0000 schrieb Carl Sorensen:
>     >     > 
>     >     > On 10/7/19, 11:27 AM, "lilypond-devel on behalf of Jonas 
> Hahnfeld via lilypond-devel" <
>     >     > 
>     > 
> lilypond-devel-bounces+c_sorensen=address@hidden
> 
>     > 
>     >     >  on behalf of 
>     >     > 
>     > 
> address@hidden
> 
>     > 
>     >     > > wrote:
>     >     > 
>     >     >     Hi all,
>     >     >     
>     >     >     lately I've been playing with gub, partly to get python3 
> packaged. Upon
>     >     >     inspection, it seems some targets are broken and some are ... 
> a bit
>     >     >     out-of-date:
>     >     >     
>     >     >     darwin-ppc: Support for applications targeting PowerPC was 
> removed in
>     >     >     Darwin 11.0 / Mac OS X 10.7, released in 2011.
>     >     > 
>     >     > That doesn't mean there aren’t people using PowerPC macs.  I 
> don't think there is a reason to eliminate this target.
>     >     
>     >     If my search skills are right, the last model with a PowerPC 
> processor
>     >     was the Power Mac G5, with the latest revision released in late 
> 2005.
>     >     That's almost 14 years ago (on October 19, if Wikipedia is correct).
>     >     
>     >     What do you think would be a reasonable time frame to eliminate 
> support
>     >     for old hardware? From my perspective, it's always a trade-off 
> between
>     >     developer time and supporting users.
>     > 
>     > In my opinion, we could eliminate PowerPC support if it were broken.  
> Unless some PowerPC user wants to step up and do the maintenance, I wouldn't 
> be concerned about removing it.  One of the theories of GUB is that the 
> developer time in minimized for maintaining cross-platform build.  But as we 
> can see, the theory doesn't always match  the practice.
>     > 
>     > But if it's not broken, I see no reason to remove it.  As long as the 
> developer time is zero, we should leave it.
>     
>     Well, then let me give some context: There's motivation to port
>     LilyPond to Python3. This means that gub needs updated spec files,
>     making the effort non-zero.
>     Based on a short try, it's not immediately possible to cross-compile
>     Python 3 for macOS. I'm not saying it's infeasible, but I'm trying to
>     find out if it's a must to get it working on all current targets. I
>     totally agree that GUB is a great idea, but does it warrant delaying
>     modernization for other targets?
> 
> I do not think it's a must to get Python3 on all targets.  I do think it's a 
> must to get Python3 on darwin-x86.  If we move to Python3 but lose 
> out-of-the-box OSX support, I think that's a step backwards.
> 
> If the move to Python3 means we lose PowerPC compatibility, but maintain OSX 
> compatibility (in the form of darwin-x86), I think that's fine.
> 
> If the move to Python3 means we lose all OSX support, except for 
> self-compiling, I think that's undesirable, and should only be implemented 
> after we give sufficient warning.
> 
> I'm afraid that Apple's new licensing of Xcode for 64-bit architecture, 
> coupled with their dropping support for 32-bit applications, means that 
> LilyPond can only exist as build-it-yourself downloads, or manually-created 
> 64-bit binaries.  I think that would be sad, but Apple gets to call the 
> licensing shots....
> 
> I hate to see the fragmentation of the build infrastructure, but maybe there 
> is no way around it.  We may be stuck on GUB for Linux and Windows, and 
> MacPorts for OSX.
> 
> Carl

Regardless of what is decided with respect to 64-bit executables for
OSX, I managed to get Python 3.7.4 integrated into gub. It compiles
fine for darwin-x86 and darwin-ppc (in addition to linux-64, linux-x86, 
linux-ppc and the embeddable package for mingw) and should be co-
installable with python-2.4.5. Would be great if somebody could check
that the binaries actually work on macOS 10.14. (I didn't bother with
freebsd because the binaries don't work AFAICT.)

Is there a maintainer for gub who could take a look at my Pull Requests
on GitHub?
https://github.com/gperciva/gub/pulls/hahnjo

Regards,
Jonas

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