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

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On 2010-02-24, Evert Glebbeek <eglebbk@xxxxxxxxxx> wrote:
> On 24 Feb 2010, at 6:13 , Peter Wang wrote:
> > Unix
> > ====
> > 
> >    liballegro.so		(symlink)
> >    liballegro.so.5.0		(symlink)
> >    liballegro.so.5.0.1
> >    liballegro_audio.so		(symlink)
> >    liballegro_audio.so.5.0	(symlink)
> >    liballegro_audio.so.5.0.1
> >    ...
> > 
> > which does not conflict with A4, which has:
> > 
> >    liballeg.so			(symlink)
> >    liballeg.so.4.4		(symlink)
> >    liballeg.so.4.4.0
> > 
> > The pkg-config files would be:
> > 
> >    allegro-5.0.pc
> >    allegro_audio-5.0.pc
> >    ...
> > 
> > which does not conflict with A4, which has:
> > 
> >    allegro.pc
> 
> Makes sense to me.
> This is almost what we have now, right?

Almost.

> > I'm worried that the version suffixes might be a bit annoying, as you
> > have to link with a number of libraries and you don't have pkg-config to
> > help you.  Ideally the DLL would have the version suffix but not the
> > import libraries, but I haven't figured out how to do that with CMake.
> > At worst I could add a custom rule to rename(copy) the import libraries
> > after they are built.
> 
> Ok.
> 
> > Mac OS X
> > ========
> > 
> > Same as generic Unix for shared libraries (.so -> .dylib)
> 
> Yup.
> 
> > I'm not sure how the frameworks should be named.  A4 has taken
> > Allegro.framework.  Maybe:
> > 
> >    Allegro-5.0.framework
> >    AllegroAudio-5.0.framework
> >    ...
> 
> I guess. I don't have a strong opinion one way or the other, since I
> don't generally use frameworks (maybe I should).
> Will the Allegro framework for OS X contain all the extrenal libraries
> (apart from OS standard ones like OpenGL, OpenAL etc.) it needs, so
> that people can just embed the Allegro framework in their application
> bundle and have an application bundle that they can distribute?

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.

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

> For that matter, do we keep the "fixbundle" utility that we have?

Anyone want to update it?

> A related (but separate) question is the target platform for OS X.
> Should we create "fat libraries" by default, that contain PPC, i386
> and x86_64 code?

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

> Related to library names, have we fully settled on header names? Right now I think we have
> allegro5/allegro.h
> allegro5/allegro_addon.h for liballegro_addon.a
> etc.

The native dialog addon is a bit inconsistent:

    allegro5/allegro_native_dialog.h
    liballegro_dialog.a

> I think that's fine. What about allegro5/allegro5.h? All it does is
> #include "allegro5/allegro.h". Do we keep it? Do we remove it?

It makes sense to remove it.

> Related: in A4 we do a version check to make sure that the headers
> that were used to compile user code is compatible with the linked
> version of the library. I think this is currently disabled for the 4.9
> WIP branch, but I think we should have that back for 5.0 - unless the
> issue that it was designed to solve for 4.x will not arise for 5.0.

I will need to dig through the list archives to remember the arguments
for the version check.

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.

Peter




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/