I think therein lies the problem. To make a standalone that has a chance of running on an arm machine, this will be in the standalone builder stack (revStandaloneSettingsMacBehavior) - specifically in the revsblibrary.livecodescript too:richmond62 wrote: ↑Fri Jan 12, 2024 7:33 am Hmm . . .
And let's fantasise for a moment that the difference is a single line of code . . .
The next question is whether it would be possible to write a stack that could open a standalone, as a text file, "inject" it with 'the ARM virus' and leave it in such a state that it actually would run on a Mac ARM machine.
Thoughts more than welcome.
Code: Select all
command revSBRemoveUnneededSlicesFromMacCode pTargetFile, pSettings
if the platform is "macos" and pSettings is not empty then
local tRemove
if pSettings["MacOSX x86-64"] is true and pSettings["MacOSX x86-32"] is not true then
put "i386" into tRemove
else if pSettings["MacOSX x86-32"] is true and pSettings["MacOSX x86-64"] is not true then
put "x86_64" into tRemove
end if
if tRemove is not empty then
replace " " with "\ " in pTargetFile
local tShell
put "lipo " & pTargetFile & " -remove " & tRemove & " -output " & pTargetFile into tShell
get shell(tShell)
end if
end if
end revSBRemoveUnneededSlicesFromMacCode
Assuming LC are still using the lipo tool in LC 9.6.11 (they might not be and might have switched to something else altogether), you'd not know unless you looked at the "revsblibrary.livecodescript" that's part of 9.6.11
(that's assuming they haven't renamed it or changed the function it uses really dramatically).
Using the new revsblibrary that ships with a non community version (apart from being a no-no licensing-wise) would probably not work as they seem to have been intent on distancing the code quite a lot from the community builds of 9.6.3 (I had a play with 9.6.10 code I think it was, just to see how different it was - just out of curiosity), and even there - there were quite a lot of noticeable differences that jumped out at me.
As an 'education piece', I may have a look at this further, but that's not to say your idea of comparing the two standalones doesn't have merit. - I think though, using this method, we'd end up with a patch that would have to be 'tacked on' to make the standalone builder aware of building for arm.
What I mean by that, is that the standalone builder goes through the motions of building for x86-64 intel Macs, then at the last step, potentially does a diff-compare to patch what is needed for arm support. I'm just coming up with ideas here - nothing definite [as of yet]...
Another point is that this wouldn't solve the issue of the IDE actually running natively under Arm either.
However, on a positive note, if we can glean what is needed to make an ARM standalone, then when it comes time to recompile the engine properly and fix the many bugs that are present in the engine - this would potentially make that job easier.
The alternative route to this would be following the intel to ARM migration checklist when compiling, which is shown on Apple's website - but again, that's at the C++ compiler stage.
A lot of this is currently over-my-head, as I'm still in the process of learning C++ to a level where it's useful to anybody.
https://developer.apple.com/documentati ... le-silicon
and
https://developer.apple.com/documentati ... -platforms
At this point, I just welcome the fact that the conversation is 'on the table' as we need to think about it.
