[vlc-devel] Too many build deps

[Rémi Denis-Courmont]

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 
manager.

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 
packagers.

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 
out.

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...

-- 
Rémi Denis-Courmont
http://www.remlab.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20080402/fe1b3966/attachment.sig>