Re: [AD] library file names (version suffixes)

[Evert Glebbeek <eglebbk@xxxxxxxxxx>]

On 24 Feb 2010, at 19:28 , Peter Wang wrote:
> I'm not sure what that would involve, so that answer is probably no.
> I think it depends if the external libraries are themselves frameworks.
> But you could probably fix up the Allegro frameworks after they are
> built, or someone would provide a precompiled framework.

Yes. Actually, I think they're just fancy directories, like application bundles. So yes.

> Actually, maybe we should only have *one* framework, Allegro-5.0.framework,
> which includes all the addons as well?

Hmm. Yes, I think that makes sense.

> Anyone want to update it?

I would, but I can't say on what timescale. I'll try to do it before April if no one else does.
That said, the core function of what it does is not really dependent on the Allegro version in use and I used the 4.2 fixbundle utility with A5.
Most of what it does is done by our makefile for Allegro's demo. The only thing it does extra that I'd really like to keep is generate the icon file. Apple have deprecated the API fixbundle uses to write the icon file and I couldn't find an easy drop-in replacement when I last checked. Apple's icon format is also poorly documented on-line (as in, not at all really) so writing one myself is also hard. The situation may have changed since I last looked, however.

> I assume that would require the user to have PPC, i386, x86_64 versions
> of the external libraries, too.  Then let's not.

Hmm, good point, I was only thinking of the frameworks that come with the OS. Actually, I think Allegro doesn't depend on too many external libraries on OS X anymore, so it may not be that much of an issue. But yes, that is what it would entail.
If and when we distribute a binary framework for Allegro (analogous to the binary development package for Windows), that probably should include all three (or at least the two Intel targets).

> The native dialog addon is a bit inconsistent:
> 
>    allegro5/allegro_native_dialog.h
>    liballegro_dialog.a

Ok. We should probably fix that. I guess liballegro_native_dialog.a would be the way to go.

> This week I got bit by the version check when I tried Matěj Týč's
> 4.4.0.1 DLL with an executable from 4.4.1 SVN, and it just quit.
> I thought something was wrong until I stepped through the debugger and
> saw the version check (which was pointless in this case).  For debugging
> it would be nice to be able to drop in different (older) versions of a
> library without artificial restrictions.

Yes, that's true. Still, that's not too hard to do, is it?
It's mainly something to protect innocent users; we, of course, know what we're doing (don't laugh. We do. Honestly. No seriously).

Evert