The fact that SDL is built as a single library causes several problems when
it comes to packaging it. The most annoying I can think of is esd / arts
support. When you make a binary package, which one do you compile in?
esd? arts? both? none? To make a useful package, you should compile both,
but this means that it will install a lot of useless dependancies in most
There is the Debian solution, where they create three different binaries:
one with esd support, one with arts and one with oss only. There is the
ports/portage solution, where build time ‘use’ variables are used; this is
ugly because binary packages are not consistant.
The best solution, IMO, is something like XMMS, where support for esd /
arts / whatever else is determined at runtime through plugins. Implementing
this inside SDL could mean that you only need a very small package with
basic support (say OSS or no audio at all) to run programs. Then, you can
add plugins when needed (i.e., you switch to KDE, so you go and install the
arts plugin for SDL).
In this direction, I’ve made a patch for the NetBSD pkgsrc system (the
packages system) to make esd and arts support pluggable. It is very
rudimentary but it seems to do its job. You can find it here:
I’ve also some minor patches for esd/arts makefile’s to build shared
libraries instead of a convenience archives.
Here are some questions about the above:
Do you find the patch correct or is it there some ugly detail that will
make it fail in some scenario?
I’ve been told that SDL_OpenAudio will assume there is a single output
device. So, with the patch above, if both arts and esd plugins are
installed, it will always pick esd (because it’s the first of the list).
Which could be the best way to make the audio output selection at runtime?
An environmental variable?
Is it there any chance that plugins will get in SDL officially, supporting
all audio devices, video and other things?
Julio M. Merino Vidal <@Julio_M_Merino_Vidal>
The NetBSD Project - http://www.NetBSD.org/