Hi Erik, you should have committed the whole patch, as you broke building
under that system, which uses a bare bones alut (which is why some of us
have moved to the OpenAL SDK, plus I use it in other projects locally, which
use the standard no AL folder setup...)
So right now, it doesn't build on windows at all out of the box, with
fredb's setup or the official OpenAL SDK.

Fred's third party lib setup includes an outdated OpenAL "sdk" and
re-distributable, and a version of alut that doesn't include
alutGetErrorString, and Olaf's patch addressed that, if I recall correctly.
That alut version basically can only do the loading of sound files, period.
No error checking, etc.
So do we want to keep supporting that setup at the exclusion of all other
possible ones because it follows the "specification" ?
Not sure that the spec says that headers have to be in AL( I couldn't find
any mention of that in the 1.1 spec, and Apple doesn't follow it either, so
I very much doubt the spec cover this. ), and it implies supporting an
incomplete, pre version 1 alut.

I don't see why a WIN32 (we define WIN32, doesn't have to be _WIN32) is such
an anathema, seeing as there is one for Apple already.
To make things more robust, we should be following the way the official SDK
works on Windows, and the solution for Fredb's third party lib is to take
out the headers from the AL folder and dump them in the include folder.
Won't solve their problem with missing alut symbols, 'though

As Geoff said, the real standard on windows, is no AL folder for the
headers.

If a mistake lasts 5 years, it's not a standard, it's a long lasting mistake
:)

I just want things to work, without having to constantly change my header
setup.


On Sun, Oct 18, 2009 at 9:07 AM, Erik Hofman <e...@ehofman.com> wrote:

> Vivian Meazza wrote:
> > Patched soundmgr_openal.cxx/hxx and sample_group.hxx with
> >
> > +#elif defined(_WIN32)
> > +# include <al.h>
> >
> > or
> >
> > +#elif defined(_WIN32)
> > +# include <al.h>
> > +# include <alc.h>
> > +# include <AL/alut.h>
>
> Olaf pointed out to me that this wasn't necessary for more than 5 yearss
> and indeed AL/* is the recommended place for the header files by
> specification. So I'll revert this to section to the way it was before.
>
> Erik
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>



-- 
Be Kind.
Remember, everyone is fighting a hard battle.
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Reply via email to