[vlc-devel] Too many build deps
rdenis at simphalempin.com
Wed Apr 2 17:52:54 CEST 2008
Le Wednesday 02 April 2008 18:05:09 Jean-Baptiste Kempf, vous avez écrit :
> Just a random question, do you want it on its special project, or do you
> want it in the projects/ in vlc Git source code, like mozilla, ActiveX
> and MacOSX who are also wrappers around libvlc ?
No offense, but while I don't mind this in the same git tree, I don't want
this in the same source tarball and build system.
The "vlc" tarball already has way too many build dependencies when targetting
desktop OSes without contrib such as BSDs and Linuxes with a packages
A few days ago, on my _main_ VLC development box I ran:
# apt-get build-dep vlc
Turns out, I am missing EIGHTY (80) direct or indirect build dependencies of
the VLC package on Debian. And, yes, I happen to be the most annoying active
developper! In other words, VLC is a gargantuan mess for downstream
When it comes to _building_ it does not help that the run-time dependencies
can be split out to different binary packages. No wonder VLC is always held
back from Debian testing. No wonder the VLC RPM packages are always missing
something that some users want. Having a decentralized run-time is one thing,
but we also need a decentralized build system. Other less serious problems
include poor automake targets scalability, configure.ac size, and vlc-config
scalability as well.
The (embryonic) .Net bindings are built outside. I am thankful that the Java
bindings is now built outside too! But Python and Mozilla... *ahem*. We
should be splitting out the vlc tarball, and that starts by letting Phonon
IMHO, we should also try to make normal plugins (not just vlc-control
bindings) buildable separately. And, we should move some plugins out of the
central libvlc build system. Especially those that provide uncommon features
with fringe libraries (gme, fluidsynth, aa, for instance), and those that
require a "large" dependencies set of their own - libqt4-dev strikes me here.
> It might be easier then for maintainers and packagers,
Oh no. It will be more difficult for packagers.
Think about GNOME, KDE, (X.org?), gstreamer...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: This is a digitally signed message part.
More information about the vlc-devel