[Openal] AL 1.1 SDK and Installer for Windows

[Panne Sven BenQ MD PBM IPM TPS 4]

Well, the directory structure looks idiotic, indeed, :-) and speaking as a "customer" of your installer, I don't care at all about any internal testing issues within Creative. All I care about is: If the API talks about a header <a/b/c/d.h>, I expect a directory a\b\c with d.h in it, everything else is confusing. And I *do* use the Microsoft tools under Windows, but (happily) not being a power user of them, I don't have a clue how to set up the include paths that the AL headers of the form <AL/blah.h> are found without modifying the sources (which is no option, of course). Or is it expected that people copy around the libs and headers into another structure? Then I can't see a point in an installer, a simple ZIP file would be enough then.

Cheers,
   S.

> -----Original Message-----
> From: Garin Hiebert [mailto:garinh at cheesetoast.net] 
> Sent: Montag, 24. Oktober 2005 17:16
> To: Panne Sven BenQ MD PBM IPM TPS 4
> Cc: garinh at cheesetoast.net; openal at opensource.creative.com
> Subject: RE: [Openal] AL 1.1 SDK and Installer for Windows
> 
> > I've just noticed another minor issue with the installer: 
> The headers 
> > are directly in OpenAL-1.1\include\. This way one can't use this 
> > directory directly to find <AL/al.h> or <AL/alc.h>, so they should 
> > probably better reside in OpenAL-1.1\include\AL\.
> 
> There was some debate at Creative about this issue, and the 
> no-AL-prefix argument won out -- I suspect many people will 
> have to set up _both_ conventions on their system to get all 
> apps compiling sucessfully.
> 
> I realize this decision will seem idiodic to some (especially 
> those who aren't using the Microsoft tools under Windows), 
> but as with other issues ("platform testing versus feature 
> testing"), the need for Creative to make support for the 
> Microsoft tools the easiest path possible won out. [...]