[AD] MacOS X dynamic linking and enduser package

[Angelo Mottola <a.mottola@xxxxxxxxxx>]

Hello

Recently on the allegro.cc forums someone asked for an enduser package 
of Allegro for OSX. Such a package is already easy to build; I coded a 
little script already in the tree, located at misc/mkpkg.sh, which 
creates a MacOS X installer package. The package contains just the 
Allegro framework (dynamic lib + headers, all packed into a single 
entity) plus it creates a symbolic link in 
usr/local/lib/liballeg-$(shared_version).dylib (equivalent to the unix 
.so) that points to the dynamic lib inside the installed framework. 
This should ensure every app compiled with the current Allegro version 
will run on the user machine... But!
There are many ways to link Allegro to a program:

- when you just do make and make install on Allegro, the dylib (shared 
lib) is built, and installed into /usr/local/lib, as a normal dynamic 
library. Coders willing to link against this can use the allegro-config 
script from the command line.
- if you do make install-framework, the dylib is built, but is 
installed into a framework structure on the system. Coders can link 
against this by either using an OSX IDE like Project Builder or XCode, 
either from the command line, but NOT by using allegro-config; they 
must specify "-framework Cocoa -framework Allegro" as the linking 
options.
- if you do make install-framework EMBED=1, it's the same as the 
previuos point, but the built framework is built to be embedded into an 
app, that is, kinda like static linking, but still really dynamic 
linking, just hidden to the user. Coders must link to Allegro as in the 
previous point, but they must also embed the framework inside their app 
bundle; this can also be done via command line, using the Allegro 
fixbundle utility.
- finally, you can build Allegro as a static library as under Unix, by 
doing make STATICLINK=1. This can be linked against by using the 
allegro-config script.

Now that's messy, isn't it? But that's due to the OSX way of handling 
dynamic libs... Allegro just supports all linking options.

Now it would be nice if allegro-config could work also when Allegro is 
installed as a framework, system wide or embedded. This would require 
modifications to allegro-config.in though, as under OSX allegro-config 
is generated on the fly from it, by using sed to change parameters. Any 
idea on how to deal with this? It'd be nice if allegro-config could 
support an additional --framework parameter, outputing "-framework 
Cocoa -framework Allegro"...

An important issue to discuss here is what allegro-config should report 
when called. Currently it outputs (among other linked libs) 
-lalleg-$(shared_version).dylib. Wouldn't be wiser for it to output 
just -lalleg.dylib or -lalleg-4.1.dylib? These would be links to the 
currently installed WIP... This way linked app will only search for 
liballeg.dylib or liballeg-4.1.dylib, so if an enduser has another WIP 
installed, it'll still work as he'll have links pointing to it 
(providing it's ABI compatible)

I'm also really considering to add symbolic links creation of 
liballeg.dylib, liballeg-4.dylib and liballeg-4.1.dylib, all pointing 
to the installed version, to the OSX enduser package, as currently the 
only link it creates is for the WIP version itself into /usr/local/lib 
(so it assumes the enduser to install the same WIP the coder used).

--
Angelo Mottola
a.mottola@xxxxxxxxxx