[Openal-devel] MP3 format token value
Sven.Panne at BenQ.com
Wed Jan 4 01:34:08 PST 2006
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.). :-)
> -----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.
More information about the Openal-devel