[vlc-devel] [vlc-commits] Remove endianess and type sizes from plugin name

[Rémi Denis-Courmont]

Le lundi 9 mai 2011 21:09:17 Felix Paul Kühne, vous avez écrit :
> >> Ehm, correct. Doesn't change the fact that I can't have different plugin
> >> caches in the same directory anymore, which is a no-go for so-called
> >> Universal Binaries.
> > 
> > You never could do that. Generating the plugins cache at build-time was
> > never supported until today.
> 
> Correct. However, I include plugin caches created prior to packaging the
> binary, which work on any device of the target architecture due to the
> limited number of supported configurations.

That was never ever supported. In VLC 1.0 and earlier, the plugin cache could 
only be generated by running VLC and was stored in the per-user cache 
directory. In VLC 1.1, the plugin cache depended on the architecture and CPU 
model and could only be generated by running native code from the final 
installation path. In VLC 1.2, only the CPU model variability was removed.

> > And now, this new possibility remains limited to native
> > builds and probably dysfunctional due to paths issues. You cannot build
> > fat binaries natively, so that is not an option for you, and never was.
> 
> I can. That's what I do for every single release, since fat binaries
> include both 32bit and 64bit Intel code plus optional 32bit PowerPC code,
> which can be easily cross-compiled and even executed on the host machine
> due to an emulator included in the OS (PPC apps behave exactly the same
> way as native ones and can even be debugged, they are just slower).

This is just plain stupid. The earliest correct/supported time the cache can 
be built is after VLC is installed. At that point, you do know the _one_ 
architecture so the issue is moot. The plugin cache content depends on the 
installation prefix. If you (try to) do generate the cache from the build 
host, VLC will ignore the content, and regenerate it at the first run.

If the user cannot write the cache, then you might as well disable the plugins 
cache; it will work just as well (even slightly faster).

If the user can write the cache, then you might as well ignore the 
(non-)problem, and let the cache be generated at first run like before.

-- 
Rémi Denis-Courmont
http://www.remlab.info/
http://fi.linkedin.com/in/remidenis