272
edits
Building FlightGear - Cross Compiling: Difference between revisions
Jump to navigation
Jump to search
→Issues: TerraGear [new section]
Hamzaalloush (talk | contribs) |
Hamzaalloush (talk | contribs) (→Issues: TerraGear [new section]) |
||
| Line 847: | Line 847: | ||
* For building OSG applications out-of-source-trees, it would make sense to introduce -DCMAKE_INSTALL_PREFIX, so that FindOpenSceneGraph.cmake can easily locate pre-installed OSG versions (as per our docs, and the existing cmake machinery in place in SG/FG), which also means that OSG would not need to be installed system-wide, while also supporting different versions at the same time. | * For building OSG applications out-of-source-trees, it would make sense to introduce -DCMAKE_INSTALL_PREFIX, so that FindOpenSceneGraph.cmake can easily locate pre-installed OSG versions (as per our docs, and the existing cmake machinery in place in SG/FG), which also means that OSG would not need to be installed system-wide, while also supporting different versions at the same time. | ||
* We keep seeing people asking for ways to have an entirely self-contained FlightGear setup that doesn't require any installation (e.g. either all files residing in a single folder or the whole binary linked statically) - we used to support this a few years go, and we even had people using FG on a USB drive, or on boot-able drives - and we commonly suggest that people first try running FG on computers before purchasing any new hardware - so it would make sense to look at what's needed to still support static builds using the mxe tool chain. This may involve making the static/dynamic configuration options configurable in the corresponding *.mk files. | * We keep seeing people asking for ways to have an entirely self-contained FlightGear setup that doesn't require any installation (e.g. either all files residing in a single folder or the whole binary linked statically) - we used to support this a few years go, and we even had people using FG on a USB drive, or on boot-able drives - and we commonly suggest that people first try running FG on computers before purchasing any new hardware - so it would make sense to look at what's needed to still support static builds using the mxe tool chain. This may involve making the static/dynamic configuration options configurable in the corresponding *.mk files. | ||
=== TerraGear === | |||
* As request for custom scenery generation arises among end-users/data developers, we see the need for a cross-platform ready set of tools handy. since then the effort started for providing Terragear on Windows(initially by {{usr|Hamzaalloush}}. It was expected that Terragear, as a scenery generation tool, that was made to deployed on a Linux server, would have portability problems. this effort would at least pinpoint issues with portability for the underlying structure of FlightGear. | |||
* The Terragear tools for scenery generation would be the ideal environment on which to bring: {{FGCquote |Small, stable, incremental changes are preferable to larger monolithic changes to ease review. |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/34183645/ |title=<nowiki>[Flightgear-devel] Policy Document and V4.X Roadmap</nowiki> |author=<nowiki>Stuart Buchanan</nowiki> |date=Jun 7th, 2015 }}}}, adhering to the FG Global roadmap for development, since we are mainly dealing with the basic building blocks for Flightgear, where a Simgear based environment is the only prerequisite. the SG abstraction layer for threading, as well as for maths are good points to investigate in this setup(as it is used throughly), as well as providing small patches upstream towards getting Simgear, Mingw64 compatible as the end-goal. | |||
* The relatively smaller number of static symbols collected from such an effort, is a good basis for investigating debugging facilities on cross-compiled binaries. | |||