Talk:Building FlightGear - Cross Compiling: Difference between revisions

: Well, I do agree that it will be easier to continue "as is" and just maintain a fork of mxe with a focus on building OSG-based applications like FlightGear, and maybe we can revisit getting mxe related changes merged upstream once we have accomplished our main objectives/priorities (i.e. being able to cross-compile FG/osgEarth on Linux for Windows using a set of downloaded deb/ppa packages) ? Once that is the case, most of the difficult work should be done, and we can look at which changes/patches have a chance of getting merged upstream. I also guess that our priorities may differ a bit afterwards - personally, I would be interested in 1) seeing the Superbuild support mxe, 2) creating a virtual appliance with "mxe.osg" pre-installed, and 3) adding better diagnostics to help Windows-users provide better bug reports (even though the latter may become more important for development/testing purposes). At that point, it should also be possible to either get in touch with the Jenkins maintainers to set up mxe.osg there, or set up our own Jenkins instance for CI purposes - e.g. using OBS or the gcc compile farm. So I think this is more about sharing our goals and identifying overlapping stuff to see how to proceed once SG/FG build/link and work correctly - for instance, some Windows folks would undoubtedly be able to use a binary fgfs.exe file "as is", while others may need an installer/patch set  (binary overlay) - equally, for FSWeekend/LinuxTag-like events it would be awesome to have a self-contained statically linked fgfs.exe file that can be put on a USB drive/CD image. So there are many areas that may sooner or later benefit from this. Personally, I think that better diagnostics integrated within the binary would tremendously help developers, especially given the large number of Windows users, and those wanting to use FG/osgEarth. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:50, 30 May 2015 (EDT)

:: i'm not very familiar with how do a backtrace on a Windows binary, other than using exception traps with the Windows SDK for driver errors, or using process monitor to check the stack and system calls. so i'm unsure how to provide this improvement in debugging facilities. i also have no experiance with CMake superbuild's, so not sure how to adopt this as a developer for the effort. in time, there will be more collaboration involved to get this done i'm sure, but right now it's good that you let me know about your overall goals. and it's good that you share them with me and what you want me to do, to my ability(which in the mean-time is only involving *.mk files), there is no conflicting goals, just different ambitions/priorities. -- [[User:Hamzaalloush|Hamzaalloush]] ([[User talk:Hamzaalloush|talk]]) 12:10, 30 May 2015 (EDT)