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

[James H. <ja...@al...>]

On Friday, 12 August 2022 09:25:23 BST James Turner wrote:
> On 11 Aug 2022, at 23:33, James Hogan wrote:
> > 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.

Note, osgXR is relatively tiny but thats already included in 3rdparty/ as a 
fallback (which gets built as static lib) in case it isn't installed 
systemwide, and at the moment flightgear is the only proper user of it (which 
drives its development) so I think that makes sense.

OpenXR-SDK is what is missing for windows builds. It provides the OpenXR 
headers and loader library (usually dynamic on linux, static on windows). A 
clone of OpenXR-SDK is <10MB so it isn't huge, and it doesn't need frequent 
updates, but its widely packaged on Linux so would be redundant there.

> > 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.

actually I've just found windows binaries here:
https://github.com/KhronosGroup/OpenXR-SDK-Source/releases/release-1.0.24

Thats 80M uncompressed, but includes CMake module stuff, headers and binaries 
for a bunch of platforms. If that were to go in windows-3rd-party I guess we 
could get away with a much smaller subset, i.e. just the static libs. Then 
just tell flightgear's cmake from build_windows_release.bat where to find OpenXR 
files. That would seem simpler tbh than having to build it from source in a git 
submodule.

There's also an OpenXR.Loader nupkg which is pretty small (5.2M uncompressed), 
only including the dynamic and static libs for each windows platform (and no 
cmake stuff), which gives an idea how small it could be.

How much do we care about the size of stuff in windows-3rd-party? Is it better 
to just copy the whole windows release in there for simplicity / 
reproducibility or should I trim it down to the necessities?

Cheers
James Hogan