Current progress
I have a working branch that builds UVTD on Linux and generates member layouts, Sol bindings, and primary Itanium vtables from LLVM DWARF while preserving the existing Windows raw_pdb path; I have not opened a PR yet.
Context
UVTD currently identifies Unreal Engine versions in filenames and stores the Windows/default function-body snippets in a flat directory, for example:
deps/first/Unreal/generated_include/FunctionBodies/
5_01_VTableOffsets_UClass_FunctionBody.cpp
5_01_MemberVariableLayout_DefaultSetter_UClass.cpp
This worked when UVTD had one Windows layout per engine version. Linux can have different member and vtable offsets for the same engine version, so generating into the same path would overwrite the Windows files.
The current Linux prototype avoids that collision by writing Linux bodies to:
FunctionBodies/Platform/Linux/
and generating shared UnrealVirtual<version>.cpp integration code that selects the Linux body with #if PLATFORM_LINUX and the existing root body otherwise.
Questions
Before preparing the PR, which repository layout would you prefer?
-
Preserve the existing root FunctionBodies/ files as the legacy/default Windows layout and add only FunctionBodies/Platform/Linux/. This has the smallest diff and preserves every existing Windows path.
-
Use a symmetric layout:
FunctionBodies/Platform/Windows/
FunctionBodies/Platform/Linux/
This is clearer, but migrating the current repository would move about 1,900 generated bodies and update roughly 1,500 includes.
-
Include the UE version as another directory level, for example FunctionBodies/Platform/Linux/5_01/, instead of keeping the version only in the filename.
There are two related cases where I would also appreciate guidance:
- Should vtable and member-layout templates use matching
Platform/Windows and Platform/Linux directories? The Linux vtable template is already platform-scoped in the prototype, but the member-layout template is currently generated into the existing unscoped directory even though it contains Linux-derived offsets.
- For shared outputs such as
UnrealVirtual<version>.cpp, member wrappers, MacroSetter.hpp, and Sol bindings, should one platform be the canonical generator, or should both platforms be required to generate byte-identical shared files?
The existing CMake and xmake include roots already allow nested FunctionBodies/Platform/... includes, so the main tradeoff appears to be repository compatibility and migration size rather than build-system support.
Current progress
I have a working branch that builds UVTD on Linux and generates member layouts, Sol bindings, and primary Itanium vtables from LLVM DWARF while preserving the existing Windows
raw_pdbpath; I have not opened a PR yet.Context
UVTD currently identifies Unreal Engine versions in filenames and stores the Windows/default function-body snippets in a flat directory, for example:
This worked when UVTD had one Windows layout per engine version. Linux can have different member and vtable offsets for the same engine version, so generating into the same path would overwrite the Windows files.
The current Linux prototype avoids that collision by writing Linux bodies to:
and generating shared
UnrealVirtual<version>.cppintegration code that selects the Linux body with#if PLATFORM_LINUXand the existing root body otherwise.Questions
Before preparing the PR, which repository layout would you prefer?
Preserve the existing root
FunctionBodies/files as the legacy/default Windows layout and add onlyFunctionBodies/Platform/Linux/. This has the smallest diff and preserves every existing Windows path.Use a symmetric layout:
This is clearer, but migrating the current repository would move about 1,900 generated bodies and update roughly 1,500 includes.
Include the UE version as another directory level, for example
FunctionBodies/Platform/Linux/5_01/, instead of keeping the version only in the filename.There are two related cases where I would also appreciate guidance:
Platform/WindowsandPlatform/Linuxdirectories? The Linux vtable template is already platform-scoped in the prototype, but the member-layout template is currently generated into the existing unscoped directory even though it contains Linux-derived offsets.UnrealVirtual<version>.cpp, member wrappers,MacroSetter.hpp, and Sol bindings, should one platform be the canonical generator, or should both platforms be required to generate byte-identical shared files?The existing CMake and xmake include roots already allow nested
FunctionBodies/Platform/...includes, so the main tradeoff appears to be repository compatibility and migration size rather than build-system support.