Re: [AD] support for mod files

[Peter Wang <novalazy@xxxxxxxxxx>]

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.

BTW, I just saw that allegro_modaudio-4.9.pc.in mentions allegro_acodec.
There is no such addon.

> > Also, there is no allegro5/png.h like there is allegro5/flac.h. So
> > really there is an entirely different design philosophy going on
> > between acodec and image.
> 
> Yes. addons/acodec basically has one separate addon for each codec in
> it. The image addon on the other hand is a single addon (where you can
> decide at compile-time of Allegro which formats it supports).
> 
> > Also, on topic of API consistency, the audio add-on is the only one
> > that doesn't use al_init_foo_addon(), as it uses al_install_audio().
> > But I shouldn't mention that, since I don't really like the mandatory
> > al_init_foo_addon() convention to begin with. ;)
> 
> 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.

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.

 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?

Peter