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

[Steve Lhomme]

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