[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