KhronosGroup / KhronosGroup/OpenXR-SDK-Source

openxr_loader dll name on Windows

Open
#528 5 comments 0 reactions 0 assignees View on GitHub
synced to gitlab
Dominant language
Python
Stars
825
Forks
306
Avg merge
1d 23h
Merged PRs (30d)
1

Description

Hello!

There is currently [an openxr PR active at libsdl-org/SDL](https://github.com/libsdl-org/SDL/pull/11601) adding openxr support.
It has support for loading openxr dynamically using `LoadLibrary` on Windows and `dlopen` on other platforms (instead of linking against the library).

However, on Windows the name of the shared library is slightly different when building a debug binary. [This happens here](https://github.com/KhronosGroup/OpenXR-SDK/blob/781f2eab3698d653c804ecbd11e0aed47eaad1c6/src/CMakeLists.txt#L136-L146).
Clearly, `openxr_loader.dll` (without `d` suffix) is the preferred name, but there is concern (vcpkg) package users will get non-functioning openxr SDL support because of this.
The suffix is configurable, but package maintainers are often hesitant to change default: developers have them for a reason.

Is the `d` suffix still required?
Current CMake Visual Studio generators put the various configurations in different folders.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start with the linked OpenXR-SDK src/CMakeLists.txt section and the Windows configuration behavior of CMake Visual Studio generators. Determine whether the debug `d` suffix is required for loader compatibility and establish the expected loader name or path for package users; done means the naming question has a clear, maintainer-approved resolution.

Written by the indexing model from the issue text.

Assessment

Tech stack
cmake
Domain
build-system
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.