Talk:Building FlightGear - Cross Compiling: Difference between revisions

Jump to navigation Jump to search
m
Line 129: Line 129:


: I don't think there's any conflicting priorities so far - the backtrace can  be provided by gdb (assuming the binaries/libs have been built with debugging symbols included). As far as I remember, WINE and gdb can even be coupled to do this automatically to some degree. But overall this is touching on my recent additions to the "Goals" section in the main article, i.e. the whole "BreakPad" idea we've been tossing around for a while. I still need to see how difficult it would be to add a breakpad.mk file and get the demo/examples working. Once that works, I can modify bootstrap.cxx and  main.cxx in $FG_SRC/Main to ensure that backtraces are provided automatically during segfaults. The CMake superbuild shouldn't be a priority at the moment, I even think that adding better diagnostics to the Windows binary is more important - the Superbuild would be nice to support at some point, because it will be maintained in fgmeta, i.e. by the main project. I have been in touch with two more Linux/Windows-based contributors who are interested in helping with testing/developing this further. But for that, it would make sense to combine patches from both branches/forks and agree to use only a single repository, and provide commit access to all interested parties. If your main interest is getting osgEarth & sg/fg working, I suggest to focus on the corresponding *.mk files, and maybe take a look at poweroftwo's batch file (as per the thread on the forum). My suggestion would be to use a separate set of flightgear-osgearth.mk and simgear-osgearth.mk files, based on the main simgear/flightgear.mk files, once those are working. Regarding debugging symbols, I mentioned this elsewhere, I would suggest to focus writing *.mk files with -DCMAKE_BUILD_TYPE=Debug or at the very least RelWithDbg, instead of "Release" - mainly for testing/development purposes. By the way, please do feel free to add your own priorities/objectives to the main article, too - we can also add a corresponding table to provide a more detailed overview. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:31, 30 May 2015 (EDT)
: I don't think there's any conflicting priorities so far - the backtrace can  be provided by gdb (assuming the binaries/libs have been built with debugging symbols included). As far as I remember, WINE and gdb can even be coupled to do this automatically to some degree. But overall this is touching on my recent additions to the "Goals" section in the main article, i.e. the whole "BreakPad" idea we've been tossing around for a while. I still need to see how difficult it would be to add a breakpad.mk file and get the demo/examples working. Once that works, I can modify bootstrap.cxx and  main.cxx in $FG_SRC/Main to ensure that backtraces are provided automatically during segfaults. The CMake superbuild shouldn't be a priority at the moment, I even think that adding better diagnostics to the Windows binary is more important - the Superbuild would be nice to support at some point, because it will be maintained in fgmeta, i.e. by the main project. I have been in touch with two more Linux/Windows-based contributors who are interested in helping with testing/developing this further. But for that, it would make sense to combine patches from both branches/forks and agree to use only a single repository, and provide commit access to all interested parties. If your main interest is getting osgEarth & sg/fg working, I suggest to focus on the corresponding *.mk files, and maybe take a look at poweroftwo's batch file (as per the thread on the forum). My suggestion would be to use a separate set of flightgear-osgearth.mk and simgear-osgearth.mk files, based on the main simgear/flightgear.mk files, once those are working. Regarding debugging symbols, I mentioned this elsewhere, I would suggest to focus writing *.mk files with -DCMAKE_BUILD_TYPE=Debug or at the very least RelWithDbg, instead of "Release" - mainly for testing/development purposes. By the way, please do feel free to add your own priorities/objectives to the main article, too - we can also add a corresponding table to provide a more detailed overview. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:31, 30 May 2015 (EDT)
== Roadmap & Priorities ==
I've added a "People" column to the corresponding roadmap tables so that people interested in anything particular can easily add new items and associate roadmap items with the corresponding contributors, which should also help others to get in touch with the right people if necessary. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:52, 30 May 2015 (EDT)


== .deb packaging ==
== .deb packaging ==

Navigation menu