Re: [AD] acodec proposal

[Matthew Leverton <meffer@xxxxxxxxxx>]

On Mon, Apr 12, 2010 at 5:54 AM, Peter Wang <novalazy@xxxxxxxxxx> wrote:
>
> There's something to be said for keeping the al_load_sample framework
> in audio (similarly, moving al_load_bitmap to the core). It provides
> the generic framework, without pulling in any specific codecs. With
> dynamic loading the argument is not so strong, of course.
>
I moved it all because it was easier. al_load_sample and family could
be part of core audio.

But then it would be tempting to bring wav support with it, which
would again bring up the same design problems.

> I've had a chance to look at the patch more closely now. If DUMB is
> found at build time, you *don't* use dynamic loading? And if is not
> found, you replicate part of the DUMB headers? What?
>
Obviously you have to replicate the function symbols with dlopen. The
only thing I did beyond that was define a single file system
structure, because I have to fill in that struct. The other structs
are left undefined.

I wouldn't be against requiring header files per se, but then there
must be a requirement that you have all headers of all external codec
libraries to build Allegro.

> What I have in mind is:
>
> 1. dynamic loading is an explicit option in the build system, and is
> the default on Windows
>
Yes. I didn't implement it because it was easier not to.

> 2. you must have foo installed to build with foo support - no header
> replication. The external dependency may change ABI!
>
That's not a problem specific to my proposal. If you use old header
files with an incompatible DLL it will always cause problems. The type
of linking is irrelevant. You *have* to static link to ensure anything
will work. My proposal doesn't eliminate that option.

Basically, if dlopen is not used to link directly to third party
libraries, I see no reason to change anything we are currently doing
with the build system.

> 3. cmake detects the name of the dll on the system, and this is hard
> coded as the name of the file to load (we might actually detect the
> name of the import library instead)
>
Again, I don't understand what you are proposing. If the library must
be installed for support, why change anything to the current system?

>
>> The point of the proposal is to:
>>
>> 1) minimize dependencies while at the same time eliminating per codec addons.
>> 2) no need to initialize acodec or individual codecs
>> 3) eliminate the need for arbitrarily choosing what is mandatory to
>> compile Allegro without experiencing any run time compatibility
>> problems.
>
> How strongly do you feel about (2)?
>
I don't really care, but loading samples / bitmaps is not a time
critical process (in terms of adding an init check) and I cannot
imagine any file type where on-demand initializing would cause
problems.

--
Matthew Leverton