[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On 13 April 2010 03:53, Matthew Leverton <meffer@xxxxxxxxxx> wrote:
> On Mon, Apr 12, 2010 at 5:54 AM, Peter Wang <novalazy@xxxxxxxxxx> wrote:
>> 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.
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.
> 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.
> Again, I don't understand what you are proposing. If the library must
> be installed for support, why change anything to the current system?
??? There seems to be some big misunderstanding :-/
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.
>>> 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.
We'll need al_init_acodec_addon() for al_load_sample() to stay in
allegro_audio.
Peter