[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On 13 April 2010 16:46, Matthew Leverton <meffer@xxxxxxxxxx> wrote:
> On Mon, Apr 12, 2010 at 11:05 PM, Peter Wang <novalazy@xxxxxxxxxx> wrote:
>> True enough for DUMB (though that struct is still unsafe), but you're not
>> going to get away with that for either FLAC or Vorbis. From a quick
>> glance, I can see that we would need to replicate constants like
>> FLAC__STREAM_DECODER_SEEK_STATUS_ERROR, and structures like vorbis_info.
>>
> If they change the values of constants or rearrange structures while
> keeping the name of the DLL the same, every dynamic linked executable
> will cease to work, regardless if dlopen() is used.
Ideally, when the ABI is changed, the DLL name would be changed as well.
But let's say that doesn't happen (possibly the reality).
Say Allegro replicates part of the headers from FLAC-1.2. Meanwhile, the FLAC
authors release FLAC-1.4, with an ABI change. A user builds Allegro without
FLAC headers, because he can. He wants to play some FLAC files, so he goes to
the FLAC website and downloads "FLAC 1.4 (dll)", the latest and greatest.
The Allegro program crashes.
That's not so far fetched, is it? I don't know about FLAC/Vorbis, but if we
were to apply the technique to libpng and libjpeg (which we won't) we would be
in that mess right now.
We'd have to update Allegro to keep up with newer versions of the
dependencies, and even then, people seem to use old versions of Allegro for
quite a long time so we'd still be fielding bug reports. I can understand
your intent, but it's too brittle for me.
>>> 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.
>>
>> Fine by me. If you are building Allegro binaries for wider distribution
>> you better have all the libraries installed so you can make sure it all
>> works. If you are building Allegro for yourself, you'd obviously install
>> the libraries that you want to use.
>>
> I was speaking in the context of my version of run time linking.
> Because the interface code is mandatory in allegro_acodec.dll (or
> audio.dll, depending on implementation), the only way to build it is
> to duplicate or require the headers of all the third party libraries.
> If the interfaces (e.g., dumb loaders) were optional, then the dynamic
> loading would be for naught, as you'd have to then recompile acodec to
> get dumb support.
You convinced me that recompiling acodec wasn't a big deal on Linux ;-)
I don't believe recompiling acodec is a big deal on Windows either.
People who have a problem with compiling Allegro can use a binary package.
>> Here's how I imagine it on Windows:
>>
>> - user installs FLAC, Vorbis, DUMB onto his development system
>> - user builds and installs Allegro (dynamic loading enabled by default)
>> - user makes his game. He uses .wav sound effects and .ogg music
>> so he links with allegro_acodec.
>>
>> (binary packages can help with the first two steps)
>>
>> Now user wants to show off his game to others. He just has to zip up his
>> .exe, and the DLLs he requires. flac.dll and dumb.dll are not required.
>>
>> So we have a monolithic acodec library, but still achieve the goal of
>> programs not pulling in libraries they don't need. Well, that was my
>> goal.
>>
> But it already effectively works that way. You have:
>
> allegro.dll
> allegro_audio.dll
> allegro_flac.dll (static link FLAC to it)
>
> In your proposal, we'd have:
>
> allegro.dll
> allegro_audio.dll
> allegro_audio-FLAC.dll (static link FLAC to it)
>
> Correct?
No, because I accepted your arguments for loading third party DLLs directly.
We'd have:
allegro.dll
allegro_audio.dll
allegro_acodec.dll
FLAC.dll
or:
allegro.dll
allegro_audio.dll
allegro_acodec.dll (static link FLAC to it)
> The only difference I see between that and the current method is that
> somebody could drop allegro_audio-vorbis.dll somewhere in the
> filesystem, and if allegro_audio were hard coded to associate ogg
> files with that particular DLL name, you could load ogg files without
> the original programmer "wanting" you to.
>
> Unless of course, the version of vorbis.dll was incompatible with
> allegro_audio-vorbis.dll because the vorbis_info struct was changed.
> ;)
>
> With mine (assuming acodec loader functions were put into
> allegro_audio) you'd have:
>
> allegro.dll
> allegro_audio.dll
> FLAC.dll
>
> or:
>
> allegro.dll
> allegro_audio.dll (static link FLAC in it)
Same as mine, then (modulo merging audio/acodec).
> I'm looking at this as a way to making building Allegro easier, while
> you are looking at it as a way to make distribution easier. (Mine
> actually does both.)
Yes, I suppose so.
> If you want to implement your version, go ahead... I cannot imagine
> why anybody would complain as it hardly changes anything except which
> library you link to.
+ It also reduces the number of #include lines and al_init_foo_addon()
calls and libraries to link against, so it's a bit more convenient
if you want more than one codec.
+ It makes the handling of audio codecs consistent with image codecs,
which the reason we started looking at this issue.
+ It reduces the number of DLLs, for those who care.
> But it really doesn't solve all of the issues
> that I care about, so I don't feel compelled to do it.
No worries. I may not get to it until the weekend, due to some distractions.
Peter