Re: [AD] acodec proposal

[Matthew Leverton <meffer@xxxxxxxxxx>]

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.

>> * "foo" autodetect full name => "libfoo.so" (UNIX) or "foo.dll" or
>> "libfoo.dll" (Windows)
>> * "foo.dll" only try foo.dll, since the extension is present.
>>
>
> Firstly, on Linux that's going to be a problem due to distribution
> quirks. On one distro, foo might be named libfoo.so, another might
> have it as libfoo-1.so.  libfoo.so might be ABI-incompatible with the
> version that acodec was compiled with, e.g. different structure sizes.
>
Distros would be free to specify a fully qualified name.

cmake .. -DLIBFOO=libfoo-1.so

> On Windows, I don't know if the problem is acute but I've seen
> different copies of FLAC around, under the names so similar problems
> might apply.
>
Then the user already is experiencing "DLL Hell," and Allegro isn't
contributing to it. We can be careful to specify names that are
version qualified, if such a standard library exists. (e.g.,
png12.dll) We only are generally working with a known subset of
external libraries; I don't particularly care if the above
al_open_library functions, etc, are even part of the documented API.

> DUMB's build system doesn't even build a shared library as far as I remember.
>
I've updated it to support that.

> I think the more robust solution is for acodec to load our own DLLs
> (like allegro_acodec-FLAC.dll) which link to FLAC. The number of DLLs
> will not increase if you statically link the dependencies into the
> Allegro modules.
>
How does that help us know that flac.dll is the same across different PCs?

--
Matthew Leverton