Weird Standalone Builder issue
paul at researchware.com
Fri Mar 25 11:04:48 EDT 2022
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
> - 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
> - 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,
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!
More information about the use-livecode