Re: gub targets + binary packages

[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