Re: [AD] Compiling errors with Allegro 3.9.29 shared/debug version.

[Shawn Hargreaves <shawn@xxxxxxxxxx>]

George Foot <george.foot@xxxxxxxxxx> writes:
> Changing the basename sounds like a good idea.  How about using
> `liballeg_shared' as the basename for the shared library,
> `liballeg_unsharable' for the static unsharable things, and just 
> `liballeg' or `liballeg_static' for the whole static library? I've never 
> much liked the word `nonshared'. :)

Yeah, static seems better than nonshared to me. Describe it by what it is, 
rather than what it isn't :-) Otherwise it could quickly get very silly, as 
we'd end up with liballeg_nonshared_nonwindows_nondos_non_kitchensink.a!

> Another alternative is to not provide `liballeg_shared.so' at all, and 
> make the script output the real name of the library (e.g. 
> liballeg-3.9.29.so).

I prefer that. Since the script is doing it, it doesn't matter how long and 
changable these names are, and the simpler the better IMHO.

> Patch 5 is based on patch 4, which is based on 3, which is based on 1, not 
> 2, so this bypasses the changes I already made to this system -- undo 
> patch 2 if you've applied it.

Ok, so basically I just apply everything except for 2?

> Maybe I should go back to characters from books...

Numbered ones do have the advantage that I can tell what order to install 
them in, when they depend on each other. I suppose you could use the names 
of related characters, so I'd know to install Novinha before Miro, but that 
only works if I've read the book in question, and can still produce some 
ambiguity, eg. does Leto come before or after Paul? :-)

> None of these will actually work until `allegro-lib' is modified.

I'd better get stuck in and do that, then.

> Oh, one last thing, concerning using `-(' and `-)' -- I've just realised 
> that I didn't bother using them in the makefiles (configure.in actually) 
> or in my hacked Speed makefile, yet there weren't any unresolved 
> references.  Is this something we'll rely on?

It's probably safe. The asm code is almost always the bottom level of the 
stack, and doesn't make calls out to other C routines. In the few situations 
where it does (eg. bank switch functions for various graphics drivers), the 
asm bank switcher is referenced by the C driver file and then makes calls 
back to that driver, so this will always work.

If it ever breaks, we can always fix it then. I doubt it will, though, since 
I don't expect we'll be writing any major new subsystems in asm! Being 
portable is a strong encouragement to use C wherever possible...



--
Shawn Hargreaves - shawn@xxxxxxxxxx - http://www.talula.demon.co.uk/
"A binary is barely software: it's more like hardware on a floppy disk."