[PD-dev] Macs to transition to ARM processors

[Christof Ressi]

> As per the usual Apple grumbling I will say "nobody is forcing people 
> to buy an Apple product."
True from a user's perspective. For open source cross-platform 
developers the story is a bit different.
> Supporting is another story, but now there are people like me to help 
> and I don't often feel so welcome when the platform I'm explicitly 
> contributing a good amount of time toward is often bashed by people 
> who don't prefer to use it.
As a Windoze dev I can relate ;-) Don't take the occasional Apple 
bashing personally. Your work is highly appreciated!
> If support is a pain, then those institutions relying on Macs, of 
> which there are many, could maybe kick back some development support 
> in some way or even a build machine or two...
Yes!

Christof

On 24.06.2020 16:00, Dan Wilcox wrote:
>
>> On Jun 24, 2020, at 12:00 PM, pd-dev-request at lists.iem.at 
>> <mailto:pd-dev-request at lists.iem.at> wrote:
>
>> so running on all
>> architectures ever supported by OSX (modulo system libraries...).
>
> To be pedantic, it has been officially "macOS" for some years now. The 
> upcoming version will be 11.0, so "OS X" will no longer be relevant 
> anyway.
>
>> why not just add arm64 to that list?
>
> I was only musing that the "Universal 2" format *might* be new. I 
> haven't read any of the details about it yet. Hopefully it's the same 
> thing with just the new architecture.
>
>> so initially, I was going to rebuke the idea oft a d_fat2 format.
>>
>> apple's labelling as "Universal 2" is a bit concerning though...
>>
>> anyhow, I don't really see why apple should make a 2nd universal format.
>> iirc, "fat" is a technology from NextStep, so its well aged, and has
>> proven itself.
>> this of course is no reason to not drop it.
>
> I mentioned that it *might* be different as there was some talk about 
> Rosetta 2 and the other emulation/virtualization layers having some 
> sort of way to optimize existing binaries for the different 
> architecture, which led me to think that they might rework the "fat" 
> approach with some additions or changes to facilitate this and/or lay 
> the groundwork for the next 10-20 years.
>
> OTOH I also cannot imagine them changing something as fundamental as 
> this unless it's *really* necessary.
>
>> more important: can you (well: they) make money with a new format?
>> i'm having a hard time here to imagine how (but then: i'm not very good
>> in imagining how to make money in general).
>
> (The following is not to IOhannes in particular.)
>
> As per the usual Apple grumbling I will say "nobody is forcing people 
> to buy an Apple product." Supporting is another story, but now there 
> are people like me to help and I don't often feel so welcome when the 
> platform I'm explicitly contributing a good amount of time toward is 
> often bashed by people who don't prefer to use it. If support is a 
> pain, then those institutions relying on Macs, of which there are 
> many, could maybe kick back some development support in some way or 
> even a build machine or two...
>
>> i don't think there are still enough ppc users left for apple to care
>> about them.
>> thinkgs might be different with i386 though.
>
> The last 32-bit only Intel Macs are from the late 00s, so there are 
> some but their numbers are probably lower than you may think. There 
> are probably fewer 32-bit Intel Macs in use now than ppc I bet, at 
> least as far as Pd is concerned.
>
>> however, i guess the biggest issue is for the developers it's getting
>> really hard to create fat binaries that cover more architectures than
>> x86_64 and i-arm64.
>> that's because there's no reasonable toolchains available that allow you
>> to do so.
>
> Right. I imagine we are looking at a minimum of needing the Xcode12 
> developer tools (ie. compiler chain), without the Xcode UI.
>
>> so the only way to produce fat binaries (that include mor ethan x86_&4
>> and amd64) is to have multiple build systems (parts of them unsupported
>> by now) and combine the artifacts into a single binary in a second step.
>
> I think it's better to have separate builds, which we already have. 
> It's already hard enough, especially concerning Tcl/Tk frameworks, 
> that I do not think making "one app bundle to rule them all" is even 
> practical... feasible perhaps, but not sustainable.
>
>> that sounds like a big enough hurdle to be a rather plump nudge for most
>> applications to support only "recent" architecture. no need to invent a
>> new format.
>
>
>
> --------
> Dan Wilcox
> @danomatika <http://twitter.com/danomatika>
> danomatika.com <http://danomatika.com>
> robotcowboy.com <http://robotcowboy.com>
>
>
>
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20200624/d65ab1e6/attachment-0001.html>