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

Rémi Denis-Courmont remi at remlab.net
Mon Dec 7 16:36:01 CET 2020


Indeed. Also it wouldn't only be shared by all VLC versions, it would be shared by all LibVLC plugin trees. If there is an app that ships its own LibVLC or its own extra plugins, it breaks too.

Le 7 décembre 2020 09:10:50 GMT+02:00, Steve Lhomme <robux4 at ycbcr.xyz> a écrit :
>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
>>>> 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
>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.
>vlc-devel mailing list
>To unsubscribe or modify your subscription options:

Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20201207/5d224728/attachment.html>

More information about the vlc-devel mailing list