[Openal-devel] MP3 format token value

[Sven Panne]

Huh? The OpenAL 1.1 spec clearly states that extension names are
case-insensitve, so it has nothing to do with Unix, autoconf, etc., it
is just a convention one has to follow when parsing the extension string
by hand. al(c)IsExtensionPresent do this automatically. But perhaps I've
missed the point here...

And I don't understand the problems with Torque (I don't have the
sources): Do they ship their own OpenAL? Anyway, relying on case in
filenames is a good recipe to ensure non-portability, as there are quite
a few case-insensitive filesystems out there, even if some of them are
case-preserving (e.g. Apple's HFS+, Window's NTFS, etc.). :-)

Cheers,
   S.

> -----Original Message-----
> From: openal-devel-admin at opensource.creative.com 
> [mailto:openal-devel-admin at opensource.creative.com] On Behalf 
> Of Carl Nicol
> Sent: Mittwoch, 4. Januar 2006 09:28
> To: openal-devel at opensource.creative.com
> Subject: RE: [Openal-devel] MP3 format token value
> 
> Extension names can be case sensitive in Unix. For instance 
> name.c is considered a C file and name.C is a C++ file. 
> 
> I think part of the issue to be considered comes with 
> building with Unix and using autoconf. Autoconf uppercases 
> everything that is used for CPP macros, which is more or less 
> a C/C++ standard. 
> 
> I'm currently working with the torque engine and have found a 
> similar problem where case gets confusing. Torque's 
> distribution of openal uses include/al/*.h and the openal 
> source uses includes/AL/*.h. Autconf does not distinguish 
> between /al/ and /AL/ and that becomes a compilation problem. 
> 
> Eventually, we need to define a set of CPP macros that can be 
> easily set by autoconf and use them through the code base.
> [...]