Re: Weird Standalone Builder issue
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
Re: Weird Standalone Builder issue
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 ~ m...@livecode.com ~ http://www.livecode.com/ LiveCode: Everyone can create apps ___ 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
Weird Standalone Builder issue
I'm on Windows 10, using LC 9.6.6, and building for macOS and Windows I have a folder called "Utilities" and in it I have the Windows version of an open source video utility called ffmpeg (specific file is just called "ffmpeg.exe". In the same "Utilities" folder, I have the macOS version of ffmpeg (called "ffmpeg" with no extension) In the standalone setting, under the Copy Files tab, I added the folder "Utilities" and then I build for macOS and Windows; Results: For Windows I get C:\Users\paul\Desktop\HR460-LC9xx\HyperRESEARCH\Windows\Utilities\ and in that folder I have BOTH "ffmpeg.exe" (windows version) AND "ffmpeg" (macOS version) as expected. I intent in the "on standaloneSaved" message to remove the one that is NOT for the target platform For macOS, there is weirdness, as I get C:\Users\paul\Desktop\HR460-LC9xx\HyperRESEARCH\MacOSX\HyperRESEARCH.app\Contents\MacOS\Utilities\ with "ffmpeg" (the macOS version) AND C:\Users\paul\Desktop\HR460-LC9xx\HyperRESEARCH\MacOSX\HyperRESEARCH.app\Contents\Resources\_MacOS\Utilities\ with "ffmpeg.exe" (the windows version) So, not what I expected? The Standalone Builder somehow places the macOS version of the utility in .app bundle in Contents\MacOS\Utilities\ and splits the Windows version out to the app bundle at Contents\Resources\_MacOS\Utilities\ How does it know that the file "ffmpeg" is a macOS compatible command line binary??? 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? ___ 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