[vlc-devel] The flat tree model into question

Rémi Denis-Courmont rdenis at simphalempin.com
Fri Jan 11 17:15:39 CET 2008


Le Sunday 06 January 2008 21:21:21 Andre Weber, vous avez écrit :
> It would be nice if somebody (xtophe?, dionoea?, j-b??) takes care of this
> source and put him under source control - after a review and possible
> correction - which I have to do... if you dislike my coding.../hacking.
>
> because the code was too big for the mailinglist I put him on my private
> "local" webspace (so the URL is only valid if I'am online)

As with the Python and Java bindings, it is not clear to me if it would not 
serve your plugin best if it were shipped as an add-on, rather than directly 
inside the main VLC source tarball.

Unfortunately, I could not download the patch, but if it adds "uncommon" 
development dependencies, and/or if it is really large => slow to compile, it 
is likely that binary packagers will ignore it, and the net effect is that 
users cannot use it.

*Maybe* this concern does *NOT* apply to your patch specifically: if it builds 
relatively fast and does not use any uncommon underlying library, it should 
be fine. However, if it needs a --enable-foobar or --with-foobar-tree, we may 
have the problem.

This is not a theoretical problem. Almost none of the binary releases of VLC 
include the Python bindings, the Java bindings, the Gnome VFS input, the Game 
music file formats support, the MIDI synthetizer and what not. VLC cannot 
depend on the entire OSS world.

Maybe we need to fix the vlc-config script to work out-of-tree (or better, use 
pkg-config instead), and we certainly need to fix the plugin API header 
files. But the VLC source tree might soon reaching critical mass id we don't 
sort this out.

-- 
Rémi Denis-Courmont
http://www.remlab.net/



More information about the vlc-devel mailing list