Hi Tat, I have a working dev setup which I rebuild automatically more often I'd should thanks to your scripts and others input. Once everything compiles and the scripts are tuned the effort to update to latest repository versions of all packages is minimal. Patience is required though since the compile time can be very long.
I just saw an opportunity to decrease the compile time dependencies. For me personally there is no need to provide prebuilt partial packages but thanks anyway. I'll start to compile the OSXLauncher soon so maybe there'll be a new thread opening soon ;-) Cheers, Jari Tatsuhiro Nishioka wrote: > Hi Jari, > > I really appreciate your passion, time and effort on this. > > However, embedding a part of alut.h code to SimGear is not a good > idea even if it is a very limited lines of code, and this is why I > haven't added my alut.h patch to SG/cvs. The reason is very easy. > Adding something that doesn't belong to your project may increase the > maintenance cost in the near future (when ALUT changes, you may need > to change your code as well). Moreover, your fix won't allow other > developers/users to use free-alut with SG/Mac. That's not a good > idea, and the same to my alut patch. > > For developer-friendliness, we can add --with-openal-framework= > option for letting you specify the path to your own OpenAL.framework. > You can add one (or more) of alut.h, free-alut, and a fix for OpenAL > (like > http://playcontrol.net/ewing/jibberjabber/defective_core_audio_mac_os.html > as James posted). > > This way we don't have to mess with the sysmtem-default framework and > the users can build FG with or without free-alut by using their own > OpenAL.framework. I can also provide a prebuilt OpenAL.framework for > saving your time. With combination of configure option, prebuilt > OpenAL.framework, and my helper build script, users can built FG > right out of the box. Of course you need to either add the framework > to FlightGear.app/Contents/Frameworks or specify DYLD_FRAMEWORK_PATH, > but it won't be a big problem, I believe. > > Tat > > p.s. I'm open to this issue, so please feel free to tell your opinion > > all developers. > > > On Nov 30, 2009, at 5:37 AM, Jari Häkkinen wrote: > >> 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 > > > ------------------------------------------------------------------------------ > Join us December 9, 2009 for the Red Hat Virtual Experience, a free > event focused on virtualization and cloud computing. Attend in-depth > sessions from your desk. Your couch. Anywhere. > http://p.sf.net/sfu/redhat-sfdev2dev > _______________________________________________ Flightgear-devel > mailing list Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
