Re: [AD] acodec proposal

[Matthew Leverton <meffer@xxxxxxxxxx>]

On Mon, Apr 12, 2010 at 1:31 AM, Peter Wang <novalazy@xxxxxxxxxx> wrote:
> On 12 April 2010 15:51, Matthew Leverton <meffer@xxxxxxxxxx> wrote:
>> On Mon, Apr 12, 2010 at 12:33 AM, Peter Wang <novalazy@xxxxxxxxxx> wrote:
>>> I think al_init_acodec_addon() should be required to maintain the separation.
>>>
>> Currently it wouldn't do anything. That is, al_load_sample() already
>> automatically calls it.
>
> (I'm sorry, the diff is a bit hard to follow and I haven't been able
> to apply it.)
>
> Doesn't this mean that as soon as you link with allegro_audio, you
> *must* link with allegro_acodec?
>
The audio add-on is simply the audio subsystem. I moved
al_load_sample() into acodec, since it is sample related.

There's three ways to do it:

1) wav+load_sample goes in audio, other codes go in acodec
2) wav+load_sample goes in acodec; audio is the audio subsystem (mixer)
3) only one audio module that combines audio/acodec

#1 is the current behavior, and useful only as a kludge to prevent
extra dependencies. You've got some I/O in audio and some I/O in
acodec. It makes no sense from an API design standpoint. i.e, wav is a
codec, and rightfully belongs in acodec. The load_sample only is
useful with codecs, so it too "should" be in acodec.

#2 is how I changed it with the diff. Everything in
<http://alleg.sourceforge.net/a5docs/refman/audio.html#audio-file-io>
(File I/O section) got put in acodec.

#3 might be a best of both worlds with my dynamic linking at run
time... assuming the likelihood of people wanting audio without any
codecs is small.

>> cmake .. -DLIBFOO=libfoo-1.so
>
> Ok. The build system should set it automatically, according to the DLL
> it found. [1]
>
The point is that if it *doesn't* find a DLL, it will link to the
named DLL (which would have a default value) at run time. The
suggestion above (-DLIBFOO=libfoo-1.so) is just a method of overriding
the guessed DLL name.

If a DLL is found, I suppose the person could still have the option to
enable run time linking.

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.

My response to the complaints with dlopen is simply that there is
absolutely no detrimental difference between hardcoding a configurable
DLL name at compile time with LoadLibrary(LIBJPEG) or at link time
with -ljpeg. An incompatible DLL is going to crash and burn one way or
the other.

If it's helpful, feel free to fork something on SVN, and I can commit
stuff to it for you to check out. Or I can send you individual files,
or the audio/acodec folder if you want to take a look.

--
Matthew Leverton