Weird Standalone Builder issue

[Paul Dupuis]

On 3/25/2022 9:05 AM, Mark Waddingham via use-livecode wrote:
> On 2022-03-24 21:07, Paul Dupuis via use-livecode wrote:
>> I'm on Windows 10, using LC 9.6.6, and building for macOS and Windows
>> ...
>> This is not a problem form me as I can use revDeleteFolder to remove
>> Contents\Resources\_MacOS\Utilities\ on the mac build and
>> revDeleteFile to remove "ffmepeg" from the Utilities folder on Windows
>> and I am left with the right utility for the right platform. I could
>> also just copy the utilities from the project folder each build during
>> the "on standaloneSaved" message handler.
>>
>> I am mostly curious as to why the Standalone Builder splits the
>> files/folder for macOS and leaves them together for Windows?
>
> So this is by design although its been so many years since this was 
> done my memory is a little hazy!
>
> I think the evolution of this was as follows:
>    - originally copy files were put next to the executable (i.e. 
> Contents/MacOS on macOS)
>    - Apple made that path read-only and things had to be put in 
> .app/Contents/Resources
>    - the s/b started doing that, but we added internal redirects to 
> the low-level file functions in the engine so code wouldn't see a 
> difference
>    - Apple then made it so that Apple executables could not be 
> launched from anywhere except from Contents/MacOS
>    - so we made it so the s/b sniffed the header of all files copied 
> for Mach-O files and left those in Contents/MacOS
>
> Basically, we've tried to make changes to Apple's structuring 
> requirements transparent to developers all the way along - and its 
> worked fine up until now, but admittedly looks a little strange if you 
> dig around into things!
>
> I've been pondering whether we should ditch the mechanism soon though:
>
>    - remove the magic redirection
>    - require code to use specialFolderPath("resources") to find 
> non-executable resources
>    - require code to use (a new) specialFolderPath("executable 
> resources") to find executable resources (which would only be 
> different to the above on macOS systems)
>    - keep the magic sniffing of files in the S/B so executables still 
> go in Contents/MacOS
>
> This may break some really old code - but would remove some rather 
> fiddly code in the engine which does the magical redirection - and 
> mean things would be structured as expected (with the new definition 
> of expected).
>
> FWIW, even with the above you would still have to branch code to do 
> what you want as the macOS exes would be in a different place (because 
> they need to be!) so it wouldn't resolve that - but at least you 
> wouldn't have been 'surprised' by what you found!
>
> Warmest Regards,
>
> Mark.
>
Mark,

Thank you! Now that you mention it, I do seem to remember a period of 
time when Apple seem to keep changing it's mind on where stuff was 
supposed to be located. With Apple's drive towards sandboxing and 
extensive permissioning system, I expect that keeping up with it, while 
trying to keep it as simple as possible for LiveCode developers, will be 
an ongoing headache for all of you in Scotland!

I DO appreciate the explanation!

-- Paul.