I am not sure if this thread is going anywhere. This will be my last post in this thread.
I think we (Eric and Tat) should decide for one strategy. They may already have done so but this is my last try to persuade a change in alut usage. As Tat outlines below there are several ways to deal with alut on mac and I use a fourth variant myself. The reason to keep bugging you on this issue is that there are many patches required to compile fg on mac. I would like to see a flighgear et al. code base that actually compiles everywhere without requiring patches. In this case it is possible to make the build path simpler on mac, removing Tats patching or the need to compile freealut. Ideally for macs, alut should be removed altogether but that is probably not an viable option. The second best option would be to include alut function declarations for the 5 backward compatibility function in the Apple OpenAL framework in soundmgr_openal.hxx (or cxx if they does not need to be exposed, alut is only used in soundmgr_openal.cxx, I think ... I still have a lot of fg code to read). Is there planned increased use of alut functionality? If not, then the choice is a no-brainer. A third option is to use freealut as Eric does and I did until recently. A forth is to use Tats strategy with adding alut.h from Creatives OpenAL framework. Which one of the four above to use depends on the implementers but when you decide please take into account that every step of user (and developer) friendliness is a good thing. And believe me, fg needs developer friendliness. Some background: I work on macs with 64-bit SnowLeopard (10.6.2) and I do not cross compile (i.e., I do not create universal binaries) and use terminal tools in the compilation process (no xcode). The discussion in this thread has been confusing since the code itself is slightly confusing, at least for an outsider, and the preprocessor makes different code selections depending on which alut.h is used. In simgear/simgear/sound/soundmgr_openal.cxx there are several #if statements. Naively one would think that compiling on macs the code path is to go through section inside #if defined( __APPLE__ ) conditionals. However, what happens depends on which alut.h is used by the preprocessor because of conditionals like #if defined(ALUT_API_MAJOR_VERSION) && ALUT_API_MAJOR_VERSION >= 1 and consequently the requirements on the underlying alut library changes. 1) Adopting my strategy to not include any alut.h at all and simply adding a declaration for alutLoadWAVFile will make the preprocessor to select the code inside the __APPLE__ conditionals. 2) Adopting Tats strategy to use Creatives alut.h will also make the preprocessor to use code inside __APPLE__ conditionals. I have not tried it myself but I have deduced it from Tats postings. 3) Use freeglut libraries and headers. This will actually make use of alut functionality not included in the Apple OpenAL framework (remember there is only 5 of them left) because of #if defined(ALUT_API_MAJOR_VERSION) && ALUT_API_MAJOR_VERSION >= 1 conditionals. The preprocessor will include code inside this type of conditionals, and actually ignore one __APPLE__ conditional. (Interestingly the code ignored is the only Apple compatibility alut function, alutLoadWAVFile, call in simgear ... is it coincidence or made on purpose?) However, this is all valid since freeglut of course provides the required underlying functionality. My experience is that this works perfectly without any need to change API names as claimed by Tat. One further confusion is that the alut.h is unnecessarily included in soundmgr_openal.hxx and alut becomes exposed to code that includes soundmgr_openal.hxx, i.e., fg source. To compile fg/source you need to have alut.h as the code is today. If nothing else, please remove the include in soundmgr_openal.hxx, the file itself does not use anything from alut.h. All alut.h usages is in the cxx-file. One of my coding rules is to avoid including header files not needed. I post this with good intent, Cheers Jari On 2009-11-29 19.35, Tatsuhiro Nishioka wrote: > On Nov 29, 2009, at 8:12 AM, Jari Häkkinen wrote: >> On 2009-11-28 23.01, Erik Hofman wrote: >>> Jari Häkkinen wrote: >>>> My comments was to elaborate on the consequences of the removed alut >>>> support by Apple. It is dangerous to use any alut.h you find on the web. >>>> As you point out using Creatives alut.h may make things simpler >>>> (macports.org is another option). I used freealuts alut.h which made the >>>> compiler to choose an unexpected path (for macs) in the source during >>>> compilation. The path chosen by the compiler required more alut >>>> functionality than provided by my mac. However, using freealut libs and >>>> alut.h, and Apples OpenAL framework works perfectly, I have done that >>>> for a while. (Now I changed strategy as outlined in other postings in >>>> this thread.) >>>> >>> From what I understand Apple is depreciating those old alut functions >>> (but still keeps hem in the library for backwards compatibility) and is >>> encouraging everyone to use the freealut package instead. And so do I. >>> >>> Erik >> >> Yes, you are right. > > > FYI, > Here is Apple's policy on ALUT thing. > http://developer.apple.com/mac/library/qa/qa2006/qa1504.html > I believe we have a few options to use ALUT thingie in your code on Mac. > > 1) Use OpenAL.framework's backward compatibility (You need alut.h that comes > with Creative's OpenAL.framework) > 2) Use OpenAL framework + free-alut (You need to change some API names for > avoiding name conflicts) > 3) Change your code not to use ALUT (without embedding ALUT source code) > > One thing you must avoid is to add free-alut's alut.h to Apple's > OpenAL.framework since this causes linker errors due to version mismatch. > > Anyway, I'll make a patch for configure.ac so we can support case 1 and 2 > above so you can safely use free-alut. > > Best, > > Tat > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
