Re: [Pyallegro] Questions about current implementation

[Juha-Matti T. <jm...@ve...>]

On Sun, Jan 30, 2005 at 08:51:52PM +0000, Grzegorz Adam Hankiewicz wrote:
> On 2005-01-29, Juha-Matti Tapio <jm...@ve...> wrote:
> > > What is the file allegro.c used for? I can rename it and the
> > > alpy module is still built.
> > If my memory serves me right, it is the original module and it is
> > not used anymore. allegro.py seems to be it's pair as they both
> > carry the $Log$-notation which I used to prefer a few years ago.
> You want to keep it?

Not really. It's propably best to dispose of it to prevent confusion.

> One thing I haven't looked yet, and you may save me the trouble,
> is how is Allegro linked into alpy? Meaning, if I build alpy
> against allegro 4.1.10 and then remove 4.1.10 and install 4.0.3,
> would alpy import this version? Or once you build alpy, it is only
> able to import the specific version it has been linked against?

setup.py calls allegro-config (on *NIX platforms) to determine the
libraries to link against. On win32 it seems to link straight to alleg.

I did a little test:

$ allegro-config --libs release
-L/usr/lib -L/usr/X11R6/lib -lalleg-4.1.15 -lm -lpthread -lXxf86dga -lXxf86vm -lXpm -lXext -lX11 -ldl

$ ldd build/lib.linux-ppc-2.3/_alpy.so
        liballeg.so.4.1 => /usr/lib/liballeg.so.4.1 (0x6fe8d000)
        libm.so.6 => /lib/libm.so.6 (0x6fdf8000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x6fd87000)
        libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x6fd66000)
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x6fd34000)
	libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x6fc3b000)
        libdl.so.2 => /lib/libdl.so.2 (0x6fc18000)
        libc.so.6 => /lib/libc.so.6 (0x6fab9000)
        /lib/ld.so.1 => /lib/ld.so.1 (0x08000000) 

Based on this I would expect alpy to continue to work with any 4.1-version
that has the same ABI but not with any other 4.x-version.

> Maybe 4.1.x vs 4.0.x was not a good example, because the ABI changes,
> but what about 4.0.0 vs 4.0.3 then? If the library can change, alpy
> will need version detection codes to modify the key constants. At
> the moment I use a custom patch so that the shift key works for
> 4.1.18, because it's define changed at some point.

Ok, constants might be a bit tricky since they come from the header
files and not the dynamic library (and alpy.py has them hardcoded).

If the constants change within the 4.1-series then I do not see any
choice but to add version detection. This might need parsing of
allegro_id.

Normally it might be nice if the constants could be autogenerated from
the headers at alpy's compile time, but this might not be possible if
they can change within minor-level versions of the library.