Ryan C. Gordon icculus at clutteredmind.org
Sun Sep 23 22:56:37 EDT 2001

> * you really should use autoconf to detect stuff like the c compiler etc.

I know...I'm a creature of habit.  I am aware that my Makefile is awkward
for those that are just jumping in, and it continues to baloon in
complexity as more features and platforms get added. It needs to be

> * might be a bad idea to assume everybody uses gnu make

Another good reason to lose the makefile.

> * SDL_sound_internal.h uses a macro _D() - bad. Names startin with an
> underscore are reserved for the compiler & the OS -> which is the
> case in OS X for _D. Change the name to e.g. DEBUG_PRINTF

Ugh. We can change it from _D, but i don't like DEBUG_PRINTF...something a
little smaller, perhaps. Let me think on this one a little.

> * "#if (defined DEBUG_CHATTER)" is quite unusual usage - normally it is
>     #if defined(DEBUG_CHATTER)

Really? I've never had trouble with it. Is it giving the MacOS X compiler
a hard time? (Actually, in general, is #ifdef a better idea?)

> * how about sticking to the unix standards - "prefix" and "DESTDIR"
> instead of "install_prefix". There are good reasons why one wants the
> prefix compiled into libs to be different from the install location
> (packaging systems come to mind)

That was just a quick hack so that there could be a "make install" target.
It, along with the rest of the Makefile, should not be considered

>    warning: ANSI C forbids const or volatile functions
> Hey, what compiler do you use I wonder? My gcc 2.95 seems to be
> different from yours :) Dropping -pedantic works nicely, though.

Odd...that's working on gcc 2.95.2 (installed from source on
Slackware/x86) and 2.95.3 (RPM from Mandrake/PPC). GCC's developers never
claimed that -ansi and -pendantic caught all violations, though.

I'd be interested in getting a list of specifically what things make your
GCC throw up, and if reasonable, change them in SDL_sound. If it isn't
reasonable, we'll drop the -ansi/-pedantic flags, but I like compiling
with as many anal warnings as possible on a given platform.

> * it is not possible to build a shared lib over here; consider using
> libtool to building libs (both static and shared) on a broad range of
> OSes. I know many people fear libtool for being overly complex, but
> it is actally not too hard to use it (and contrary to common believe
> does not require automake. although automake integrates well with it).

Another good reason to scrap the makefile.

> * static lib does not work here either, requires some flags

Another good reason to scrap the makefile.

> * even if this was fixed static lib will not work since you do not
> call ranlib, which is required on Darwin/MacOS, like on many other
> OS... libtool would help here, too, or at least use autoconf to
> detect about this.

Another good reason to scrap the makefile.

(Seeing a pattern?  :)  )

> I do not want to make this down or anything, just list issues I
> encountered and suggestions on how you might overcome them. feel free
> to act on this as it pleases you.

No, it is actually very much appreciated. Not only do we have some things
to tackle, now, you actually took the time to try and build on a new
platform, which is very good of you.

If you get bored and want to put together some initial autoconf work for
me, I'll gratefully accept it. Otherwise, I will get around to it, but
it's one of those ugly jobs that I have to motivate myself to do.  :)



More information about the sdlsound mailing list