EmilandClaude Sonnet 5
faabfc2cb4
The literal thing nothing on this dev machine can verify: whether the build actually runs on Windows at all. Solved by having real CI do it — ubuntu-latest and windows-latest both build the native Box3D/miniaudio shims from source via CMake, build and test the full .NET solution, stage a shippable configuration (engine.windowing/assets/render/input/physics/ audio + physics-demo-game — engine.editor deliberately excluded, that's M4's actual "done when"), and then run it headless against samples/ PhysicsDemo for 200 frames, asserting DemoBox settled at y≈1.0 in the resulting dump. Real physics, real scene load, real plugin loading, proven on both platforms, not just built. Required restructuring the native Content items into per-OS ItemGroups (native/linux-x64/ vs native/win-x64/, selected via $([MSBuild]::IsOSPlatform(...))): linux-x64's .so is committed (built and verified here); win-x64's .dll is never committed — nothing here can build or run one to verify — and only ever exists as something the Windows job produces fresh, in-place, right before `dotnet build`. Caught one real bug dry-running this exact staging locally before trusting it to a workflow run: PluginHost.Load calls Assembly. LoadFromAssemblyPath, which throws on a relative path — the verification step's `--plugins ../../plugins` failed immediately with "is not an absolute path." Every manual verification earlier this session happened to always pass an absolute --plugins path, which is exactly why this never surfaced before. Fixed by resolving to an absolute path before invoking Engine.Host. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N1qPfzq8TDCUMFMV3UwV5N
45 lines
2.0 KiB
XML
45 lines
2.0 KiB
XML
<Project Sdk="Microsoft.NET.Sdk">
|
|
|
|
<PropertyGroup>
|
|
<!-- Generates the deps.json AssemblyDependencyResolver needs to find
|
|
this plugin's dependencies — see PluginLoadContext in Engine.Kernel,
|
|
and the same property on the other native-facing plugins. -->
|
|
<EnableDynamicLoading>true</EnableDynamicLoading>
|
|
</PropertyGroup>
|
|
|
|
<!-- The compiled native shim (Box3D folded in) — see
|
|
native/physics-native/. Copied straight into this plugin's own
|
|
output directory (not a runtimes/<rid>/native/ NuGet-style path):
|
|
DllImport's default unmanaged-library probing already checks the
|
|
calling assembly's own directory, and PluginLoadContext.
|
|
LoadUnmanagedDll falls back to that default probing whenever its
|
|
AssemblyDependencyResolver doesn't recognize the name (returning
|
|
IntPtr.Zero, not failing outright) — confirmed empirically, see
|
|
PhysicsWorldTests.
|
|
|
|
Picked by the BUILDING machine's OS, not cross-compiled: linux-x64's
|
|
.so is committed (built and verified here); win-x64's .dll is never
|
|
committed — nothing here can build or run one to verify — and is
|
|
instead produced fresh by .github/workflows/build.yml's Windows job
|
|
right before `dotnet build` runs, landing at exactly this path. -->
|
|
<ItemGroup Condition="$([MSBuild]::IsOSPlatform('Linux'))">
|
|
<Content Include="native/linux-x64/liblingua_physics.so">
|
|
<Link>liblingua_physics.so</Link>
|
|
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
|
|
</Content>
|
|
</ItemGroup>
|
|
|
|
<ItemGroup Condition="$([MSBuild]::IsOSPlatform('Windows'))">
|
|
<Content Include="native/win-x64/lingua_physics.dll">
|
|
<Link>lingua_physics.dll</Link>
|
|
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
|
|
</Content>
|
|
</ItemGroup>
|
|
|
|
<ItemGroup>
|
|
<ProjectReference Include="..\..\..\src\Engine.Kernel\Engine.Kernel.csproj" />
|
|
<ProjectReference Include="..\Engine.Physics.Contracts\Engine.Physics.Contracts.csproj" />
|
|
</ItemGroup>
|
|
|
|
</Project>
|