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.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
