Re: [AD] support for mod files

[Elias Pschernig <elias.pschernig@xxxxxxxxxx>]

On Tue, 2010-04-06 at 00:35 +1000, Peter Wang wrote:
> On 2010-04-05, Elias Pschernig <elias.pschernig@xxxxxxxxxx> wrote:
> > On Mon, 2010-04-05 at 08:50 -0500, Matthew Leverton wrote:
> > > On Mon, Apr 5, 2010 at 8:23 AM, Matthew Leverton <meffer@xxxxxxxxxx> wrote:
> > > > Doesn't the singular init function cause every format to be linked to
> > > > the executable as soon as one format is used?
> > > >
> > > Testing on Linux, it seems that just linking against allegro_audio is
> > > enough to bring in libflac, libvorbisenc, libvorbis, libogg,
> > > libsndfile, etc. However, it doesn't bring in libdumb... Seems strange
> > > to me. Linking against allegro_modaudio then brings in libdumb.
> > 
> > True, same here. I guess there's a mistake somewhere in our build - the
> > audio addon should not depend on any codecs as far as I understand.
> 
> Doesn't happen here with 4.9.19.

Yeah, it's strange:

elias@xxxxxxxxxx> ldd lib/liballegro_audio-debug.so
	linux-vdso.so.1 =>  (0x00007fff181ff000)
	liballegro-debug.so.4.9 => /home/elias/prog/allegro/git/build/lib/liballegro-debug.so.4.9 (0x00007f6b3d7c2000)
	libpulse-simple.so.0 => /usr/lib/libpulse-simple.so.0 (0x00007f6b3d595000)
	libpulse.so.0 => /usr/lib/libpulse.so.0 (0x00007f6b3d354000)
	libasound.so.2 => /usr/lib/libasound.so.2 (0x00007f6b3d074000)
	libm.so.6 => /lib/libm.so.6 (0x00007f6b3cdf0000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x00007f6b3cbd3000)
	libSM.so.6 => /usr/lib/libSM.so.6 (0x00007f6b3c9ca000)
	libICE.so.6 => /usr/lib/libICE.so.6 (0x00007f6b3c7af000)
	libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f6b3c478000)
	libXext.so.6 => /usr/lib/libXext.so.6 (0x00007f6b3c266000)
	libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x00007f6b3c05c000)
	libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0x00007f6b3be55000)
	libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x00007f6b3bc53000)
	libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x00007f6b3ba4a000)
	libGL.so.1 => /usr/lib/libGL.so.1 (0x00007f6b3b871000)
	libGLU.so.1 => /usr/lib/libGLU.so.1 (0x00007f6b3b600000)
	libc.so.6 => /lib/libc.so.6 (0x00007f6b3b291000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f6b3dcee000)
	libpulsecommon-0.9.19.so => /usr/lib/libpulsecommon-0.9.19.so (0x00007f6b3b045000)
	libXtst.so.6 => /usr/lib/libXtst.so.6 (0x00007f6b3ae3e000)
	libwrap.so.0 => /lib/libwrap.so.0 (0x00007f6b3ac33000)
	libsndfile.so.1 => /usr/lib/libsndfile.so.1 (0x00007f6b3a9d0000)
	libdbus-1.so.3 => /lib/libdbus-1.so.3 (0x00007f6b3a791000)
	librt.so.1 => /lib/librt.so.1 (0x00007f6b3a589000)
	libdl.so.2 => /lib/libdl.so.2 (0x00007f6b3a384000)
	libuuid.so.1 => /lib/libuuid.so.1 (0x00007f6b3a17f000)
	libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f6b39f62000)
	libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f6b39d5f000)
	libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00007f6b39b55000)
	libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00007f6b3994e000)
	libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0x00007f6b38628000)
	libnvidia-tls.so.1 => /usr/lib/tls/libnvidia-tls.so.1 (0x00007f6b38526000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f6b38215000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f6b37ffe000)
	libnsl.so.1 => /lib/libnsl.so.1 (0x00007f6b37de3000)
	libFLAC.so.8 => /usr/lib/libFLAC.so.8 (0x00007f6b37b98000)
	libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2 (0x00007f6b377be000)
	libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0x00007f6b37590000)
	libogg.so.0 => /usr/lib/libogg.so.0 (0x00007f6b3738a000)
	libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f6b37185000)


> > I don't like it at all either. I kinda get around it by having a wrapper
> > which just calls all of them. The only way I see to improve it is if you
> > add runtime loading for all addons though. Which might not be a bad idea
> > - question is just if the amount of coding required is really worth the
> > trouble. Right now you can either be lazy and just always include
> > everything (so you distribute 1 or 2 MB worth of code you might not use
> > right now), *or* do a compile-time configuration to include just what
> > you want. With dynamic loading you can be lazy and always compile all
> > addons then decide at runtime which DLLs to distribute.
> 
> On Linux the compile time method is fine.  I mean, you definitely will
> have libpng and libjpg anyway, and probably vorbis and FLAC, so
> depending on them or not makes no real difference.

I agree. I still think runtime loading would be the nicest option
(especially as we could then also use it for more things eventually) but
for now it's not necessary.

> On Windows, well, people probably will be too lazy to recompile a
> version of Allegro with the minimal amount of dependencies so they end
> up distributing unnecessary FLAC and Ogg Vorbis DLLs.

Yes, with runtime loading this would again be handled best. Distribute
the DLLs you want available, leave out the others. The game will always
load and be able to check at runtime which DLLs it has available and
which not. But I won't implement it myself...

>  From this POV, the image addon should probably act like the audio
> addons.  But I get the feeling most people want PNG support anyway,
> and many people probably want JPG support.  So would it be worth
> splitting image up into _image, _png and _jpg?
> 

Probably not - but as Matthew said, doing it might encourage more image
format addons. However I don't see which formats besides .png and .jpg
would make any sense. Things like animations or vector data or layers
couldn't be handled so those two are the formats to use for lossless and
lossy compression.

-- 
Elias Pschernig <elias.pschernig@xxxxxxxxxx>