[vlc-devel] [PATCH 3/7] package/macosx: skip cache generation when cross-compiling

[David Fuhrmann]

> Am 07.12.2020 um 08:10 schrieb Steve Lhomme <robux4 at ycbcr.xyz>:
> 
> On 2020-12-06 17:43, Felix Paul Kühne wrote:
>> Hello,
>>> Am 30.11.2020 um 19:06 schrieb David Fuhrmann <david.fuhrmann at gmail.com>:
>>> 
>>>> Am 29.11.2020 um 20:12 schrieb Felix Paul Kühne <fkuehne at videolan.org>:
>>>> 
>>>> From: Felix Paul Kühne <felix at feepk.net>
>>>> 
>>>> ---
>>>> extras/package/macosx/package.mak | 6 +++++-
>>>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>>> 
>>>> diff --git a/extras/package/macosx/package.mak b/extras/package/macosx/package.mak
>>>> index 1423d7874e..0e60cc838a 100644
>>>> --- a/extras/package/macosx/package.mak
>>>> +++ b/extras/package/macosx/package.mak
>>>> @@ -61,7 +61,11 @@ endif
>>>> 	## Install binary
>>>> 	cp $(prefix)/bin/vlc $@/Contents/MacOS/VLC
>>>> 	## Generate plugin cache
>>>> -	bin/vlc-cache-gen $@/Contents/MacOS/plugins
>>>> +	if test "$(build)" = "$(host)"; then \
>>>> +		bin/vlc-cache-gen $@/Contents/MacOS/plugins \
>>> 
>>> This patch has syntax issues (missing ";" ).
>>> 
>>>> +	else \
>>>> +		echo "Cross-compilation: cache generation skipped!" ; \
>>>> +	fi
>>>> 	find $@ -type d -exec chmod ugo+rx '{}' \;
>>>> 	find $@ -type f -exec chmod ugo+r '{}' \;
>>>> 
>>> 
>>> Also, we need to generate the plugin cache, in my opinion, prior / during the release signing process. Otherwise the bundle might get corrupted (and has an invalid signature) once a plugin cache is (maybe) added later.
>> Ideally, the plugin cache should not be stored in the plugins folder within the application bundle but some place else such as ~/Library/Caches.
> 
> That means the plugin cache would be shared among all versions of VLC you run on your system. That doesn't seem right.
> 
>>> Is there a way to build vlc-cache-gen as a build-tool, so it can be executed on x86?
>> No, because vlc-cache-gen needs to load the plugins to generate the cache. When executing a x86 binary on plugins compiled for ARM on a x86 Mac, it will tell "No plugins in $PATH“ and create an empty cache as it cannot run the plugins.
>> FYI, I ran a small test on my ARM Mac:
>> time vlc vlc://quit <vlc://quit> is 0,33s with a cache and 0,38s without. so yes, there is a speed advantage, but it’s small, so shipping the first VLC-Mac for ARM without a cache could be „fast enough“. (FYI, in translation mode, the x86_64 binary takes 0,47s.)
>> The other alternative is would be to ship an ARM binary that is compiled natively on an ARM Mac and therefore includes a cache.
>> If we decide to ship a binary without a cache, it seems to be generated never (and therefore the package will not be invalidated) unless the user decides to execute the app with —reset-plugins-cache.
> 
> It might be possible to detect the first run (or a missing cache) and generate the cache then.

No application shall modify any file inside the application bundle after installation, otherwise the signature will become invalid. And this might potentially cause other runtime problems later on, like broken security permissions, etc.

So generating the cache after installation works only if the cache is stored outside of the application bundle. But I think this idea does not easily work as mentioned above, and as also discussed a while ago if I remember.

Currently the cache is (re)generated during the final release signing step (it must be generated after the libraries / plugins are signed, and before the actual plugins.dat file is signed as well). So one solution could be to do the release signing on an arm mac (which makes the release process more restricted and harder to do).

Or we ship without cache for now.

BR. David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20201207/67accad0/attachment.html>