Weird Standalone Builder issue

[Mark Waddingham]

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 Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps