Talk:Building FlightGear - Cross Compiling

From FlightGear wiki
Jump to navigation Jump to search

Build Errors

is it a good idea to update the page with the build errors encountered and the possible solutions(like for example with OSG) so as to make the status more informative? -- Hamzaalloush (talk) 18:22, 18 May 2015 (EDT)

sure, why not - we should add anything here that may help others at some point, even if it's just for historic reasons, i.e. the project having a history before it gets a visible commit log. Besides openscenegraph.mk still seems to contain a bunch of static-build related build flags as far as I can tell, are you sure that dynamic/shared builds are intended to be supported ?--Hooray (talk) 18:38, 18 May 2015 (EDT)
yes, you have to change the flags to build dynamically, and this is how you finally get shared libraries into /bin, else they get built into /lib with the *.a prefix as static. actually some shared libraries actually do get installed while some require linking with the plugins before encountering error , this is what i intend to work on -- Hamzaalloush (talk) 18:52, 18 May 2015 (EDT)
It is usually a good idea to document problems and how they got solved. If not for else then for to not do them again.
It could also potentially help similar endeavors later on.
Johan G (Talk | contribs) 06:38, 19 May 2015 (EDT)

Required OSG Plugins

can we get a subset of required plugin needed by flightgear? we can simply disable the faulty ones of the time bieng if they are not needed? mxe allows you to apply patches to source from the *.mk file as well for this -- Hamzaalloush (talk) 18:58, 18 May 2015 (EDT)

sounds like a plan, I'd use grep -R and the OSG_USEPLUGIN macro in $SG_SRC and $FG_SRC to see what's important [1]. --Hooray (talk) 19:06, 18 May 2015 (EDT)

Minimizing the needed number of MXE packages

the default 'all-filtered' make target, builds 367 packages in a clean environment, only 107 out of 367 are built using MXE's own dependency walker in the Makefile if 'openscenegraph' is passed as a parameter to 'make'. few packages can be excluded by disabling uneeded OSG plugins, and dependencies of further packages. -- Hamzaalloush (talk) 21:16, 22 May 2015 (EDT)

mxe specific tool chain

as far as I know, mxe should be quite able to only build those dependencies that are needed for FG - i.e. plib/openal/simgear/osg which should in turn pick up their own dependencies automatically. So it's mainly a matter of making sure that dependency resolution is working correctly. If you are really referring to the underlying tool chain and not just dependencies, I am not sure what might be optional ? But I guess it would make sense to come up with 2-3 *.mk files for the main FG dependencies, so that the a corresponding build environment can be automatically created by the mxe installer, and which can be used by the Superbuild afterwards. --Hooray (talk) 13:55, 23 May 2015 (EDT)

as i experienced this works very well(95% of the time, MXE pulls only required packages), but due to some packages that introduce dependency bloat, such as for instance OSG compiles with ffmpeg(we don't need this), so this nice package pulls all the audio tools such as x264, flac encoders etc. we can minimize this in our fork, such that ffmpeg is disabled completley, further elimination of a dozen packages consisting of only encoders built for ffmpeg, i'm sure i can find other examples like this as well. FG main dependancies such as simgear will be included in the 'requirements' for fgfs.mk, so whenever you call 'make fgfs' it builds it. for the Superbuild, i'm thinking an extra automation step is required preferably by a script in $(MXE_ROOT)/tools that copies all the dll's and binaries to the expected Building_using_CMake_-_Windows#Directory_tree. -- Hamzaalloush (talk) 16:40, 23 May 2015 (EDT)