| Re: [AD] support for mod files |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
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.
> 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.
--
Elias Pschernig <elias.pschernig@xxxxxxxxxx>