[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On 12 April 2010 17:04, Matthew Leverton <meffer@xxxxxxxxxx> wrote:
> 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.
Thanks, I didn't catch that you moved al_load_sample().
> 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.
Makes sense.
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.
> #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.
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?
What I have in mind is:
1. dynamic loading is an explicit option in the build system, and is
the default on Windows
2. you must have foo installed to build with foo support - no header
replication. The external dependency may change ABI!
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)
> 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 prefer if we have more leeway
in case we need it in future. We barely managed to work around the
lack of an initialisation function the primitives addon previously.
Peter