| Re: [AD] support for mod files |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Mon, 2010-04-05 at 08:23 -0500, Matthew Leverton wrote:
> On Mon, Apr 5, 2010 at 8:08 AM, Elias Pschernig
> <elias.pschernig@xxxxxxxxxx> wrote:
> > Won't work right now because al_init_modaudio_addon() must be called to
> > add ".mod" to the list. However, it would work if we do it like in the
> > image addon - that is have only one al_init_acodec_addon(), which has
> > compile-time check for the included formats. I forgot why we did things
> > differently for image and audio formats originally - but it seems like
> > the better way to me.
> >
>
> Doesn't the singular init function cause every format to be linked to
> the executable as soon as one format is used? e.g., Just because I
> create an Allegro version with JPEG support doesn't mean I want my
> executable that only uses PNGs to be dependent on the JPEG DLLs.
No, it's all compile-time. addons/image/iio.c has #ifdefs for PNG and
JPEG. So if you disable them they don't get compiled in and they don't
get linked in. And we do check at runtime if the format is available. We
just don't expose the information to the user before they try loading an
image, which was Thomas' suggestion and which I think we should do.
> Personally, I'd prefer separate init functions for both audio and
> images if it prevented that behavior. That, and I don't think the
> audio/image modules should "know" about the internals of the codec
> functions from a design perspective, but that's just a minor thing
> worth overlooking if it really increases usability.
>
> It's not a big deal to me either way, but I agree they should both
> work the same way. I'd be in favor of making the image initialization
> work like the audio module if it potentially lessened dependencies.
>
Unless I'm mistaken it's like I said above - so I'd be for making audio
work like image... however I seem to remember there was some other
reason.
--
Elias Pschernig <elias.pschernig@xxxxxxxxxx>