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

[Felix Paul Kühne]

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.

> 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 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.

Regardless of what we do, are you ok with me merging the patch?

Best regards,

Felix