Re: [Flightgear-devel] VR Options Menu Is Not Available In Daily Build

[James T. <ja...@fl...>]

> On 11 Aug 2022, at 23:33, James Hogan via Flightgear-devel <fli...@li...> wrote:
> 
> I want to get my head around this so I have something to test. The main 
> options I can see to get OpenXR loader included in the windows builds are:
> 
> 1) Add https://github.com/KhronosGroup/OpenXR-SDK <https://github.com/KhronosGroup/OpenXR-SDK> to flightgear/3rdparty. Not 
> ideal IMO as the cmake stuff assumes a top level project, so it'd need 
> modifying, and on Linux at least it should very much be a distro thing.

Not ideal for something large and complex

> 2) Add OpenXR-SDK as an external project to flightgear, so it fetches it 
> automatically (or possibly from 3rdparty - if that can work). Also not ideal 
> IMO, and none of the other dependencies do that yet.

Been trying to avoid that one, otherwise we would do the same for OSG and and simgear

> 3) Add OpenXR-SDK as a git submodule of fgmeta and ensure it gets built before 
> flightgear is configured for windows, so flightgear cmake can pick up the openxr 
> loader static library and enable VR.

This one is possible but forces everyone to pull osgXR - also not totally ideal but I guess it’s small.

> 
> Option 3 seems best to me. I can see from the following log:
> http://build.flightgear.org:8080/job/Windows-nightly/4461/console <http://build.flightgear.org:8080/job/Windows-nightly/4461/console>
> That various submodules of fgmeta are updated, then it goes on to run the 
> build_release_windows.bat script.

Yes exactly

> 
> Does the nightly build use fgmeta/CMakeLists.txt at all, or is that just 
> another way of doing the same thing as the build_release_windows.bat script?
> I don't see any mention of building OSG in build_release_windows.bat...
> Should openxr loader be built separately somehow like osg is, since it isn't 
> going to need regular rebuilding?

Sooo the normal option on Windows is to add osgXR binaries to windows-3rd-party : that’s what we do for all distro supplied stuff *except* OSG itself, which we build on Jenkins. So you’re kind of in the limbo between ‘fairly static stuff’ (libpng, zlib, etc) and stuff we build ourselves (OSG, SimGear). Given that, option 3 does seem reasonable to me.

The top-level CMakeList.txt in fgmeta is not used, because while in theory it makes sense, the resulting IDE project is not usable (that was the goal, to be able to open everything in one IDE, make a change in a simgear .cxx file, and have just the right pieces rebuild) : the minute you have separate install steps, getting things to work is a bit ugly. So the Jenkins builds all use a foo-script for each platform (which live inside fgmeta) and just use CMake inside simgear/flightgear/OSG.

(It’s been a while since I tried a top-level CMakeList.txt: there’s been some advances in what CMake can do in this area, if anyone wished to try again)

Kind regards,
James