[Openal] AL 1.1 SDK and Installer for Windows

[Panne Sven BenQ MD PBM IPM TPS 4]

Well, I think that a few people are missing the critical point here: It is
very obvious that one can fix the current broken installer by either moving
around header files or by mutilating otherwise portable code with #ifdefs
for Creative's paths. My main point is that the current installer needlessly
introduces fragmentation, and if we let Creative get away with it again, it
is only a matter of time that at least half of the programmer community
thinks that '#include <al.h>' is the standard way to include the AL header.
OK, we haven't specified an OpenAL/ALUT ABI yet, but given the current
discussion, I think it will be necessary. :-(

Be honest, guys: If you don't know about OpenAL before and you see that code
like

#ifdef _WIN32
#include <al.h>
#else
#include <AL/al.h>
#endif

is necessary, what would your impression be? My impression would be: "Oh my
god, just another small sweet project in its infancy..." and I would think
twice before I'm considering it a serious candidate for my own project.

And I don't really see a problem with the EAX SDKs: Either tell the EAX
users to fix the paths or copy files around or upgrade the EAX SDK, but
don't tell the rest of the world to fix something caused by a Creative-only
issue...

Cheers,
   S.

> -----Original Message-----
> From: openal-admin at opensource.creative.com 
> [mailto:openal-admin at opensource.creative.com] On Behalf Of 
> Elden Armbrust
> Sent: Mittwoch, 26. Oktober 2005 04:23
> To: Garin Hiebert
> Cc: openal at opensource.creative.com
> Subject: Re: [Openal] AL 1.1 SDK and Installer for Windows
> 
> *Flexes his clicking muscles*
> Garin is most certainly right here.  A simple #ifdef can make 
> the code cross platform capable (not compatible) so that you 
> don't have to make open source projects a pain to work with.  
> If you reference the includes where they are located by 
> default, even non-programmers shouldn't have a problem 
> installing the latest SDK to it's default location to compile 
> against.  Simply make openal 1.1 a dependency, and call it a 
> day, I would think.  If you need to update older projects 
> there are tools such as sed under Linux console and Search & 
> Replace in many Windows text editors (such as Wordpad).  But 
> like Garin said...there's always cp/copy.