How do we treat additional/optional library (read codecs) in the vlc source tree?

[Jean-Paul Saman]

Samuel Hocevar wrote:
> 
> On Sun, Nov 25, 2001, Jean-Paul Saman wrote:
> 
> > 1. How do we treat additional/optional library (read codecs) in the vlc
> > source tree?
> 
>    I wouldn't exactly call libmad a codec ; your plugin which uses
> libmad is the codec, but libmad itself shouldn't be added to the vlc
> tree, for all the reasons you already mentioned.
> 
>    libdvdcss doesn't really follow this rule, because at the beginning
> all its code was part of vlc and we weren't exactly sure which parts
> should stay within vlc and which ones would have to go into the lib. But
> libdvdcss will eventually be a completely standalone piece of software.
> 
And libdvdread, BSDI_dvdioctl and MacOSX stuff. It is unclear what the
semantics for the extra directory are.
I see a trend here ;-)

> > - Treat libmad audio decoder as a library (either static or dynamic). In
> > this way it is possible on an iPaq to let applications share the library
> > without having to staticly link it with every app. This saves valuable
> > FlashROM space.
> 
>    Having the module as a plugin dynamically linked to libmad is a good
> idea, since it will only be loaded (and useful at all) if libmad is
> available.
> 
> > - Where to put those optional or additional codec libraries? My first
> > thought was to use <top-level dir>/extras for this, but it can also be
> > e.g.: <top-level dir>/lib which is perhaps a better place.
> 
>    They should be installed separately. And plugins using these
> libraries should be treated exactly like any other vlc plugin.
> 
Any way the configure script and the Makefile will have to refer to
"mad.h" and the libmad library path to link against. Not including it in
the source tree requires one of us always to build the libmad variant
and provide a package on the website. 

The usage scenario is then this: 
+ First untar mad.x.x.x.tgz, configure, compile libmad and install. 
+ Secondly Untar vlc-x.x.x.tgz, configure, compile and create package.

I must say that I agree on this scenario. It is somewhat more work then
simply untar, configure, compile and create package. But it is not a big
deal. It just seemed convenient to me.

> > 2. Is vlc going to support 'make dist-ipaq' ?
> 
>    I'm not qualified to answer this question. But isn't the ipkg/
> directory Christophe created enough?
> 
At time of writing I had not seen the latest cvs source. 

> > The current source code directory does not provide a generic mechanism
> > for where to keep the necessary files for this. E.g. vlc.spec (redhat)
> > is in the top-level directory and there is a debian directory. Shouldn't
> > we solve this in a more generic way, e.g.:
> > <top-level dir>/dist/redhat
> > <top-level dir>/dist/debian
> > <top-level dir>/dist/familiar (for ipaq)
> > etc.
> 
>    This won't work for Debian, for instance. dpkg-buildpackage expects
> the debian/ directory to be located in the top-level directory. I don't
> think we should panic about this issue yet, there are only "debian",
> "ipkg" and "vlc.spec" for the moment. Let's start thinking about this
> when we have ten of them :-)
> 
Did not know that debian required this. It is better to think about it
now and perhaps act a little later, then cleaning up the mess later ;-)
With other words something for on the roadmap ;-)

> --
> Sam.