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
48 lines
1.4 KiB
Plaintext
48 lines
1.4 KiB
Plaintext
## .NET
|
|
bin/
|
|
obj/
|
|
*.user
|
|
*.suo
|
|
.vs/
|
|
|
|
## Rider / VS Code
|
|
.idea/
|
|
.vscode/
|
|
*.DotSettings.user
|
|
|
|
## OS
|
|
.DS_Store
|
|
Thumbs.db
|
|
|
|
## Build output
|
|
out/
|
|
artifacts/
|
|
|
|
## scripts/stage-plugins.sh's output — regenerated from plugins/, not source.
|
|
.stage/
|
|
|
|
## ImGui's own persisted window layout (position/size/open-state) — a
|
|
## per-machine editing session preference, not project source, same
|
|
## category as an IDE's own workspace state.
|
|
imgui.ini
|
|
|
|
## CMake build output and FetchContent's cloned dependencies (Box3D) for
|
|
## native/*-native/ — regenerated by cmake -S . -B build, not source; only
|
|
## the built liblingua_physics.so (checked in under plugins/engine.physics/
|
|
## Engine.Physics/native/) is what the engine actually ships.
|
|
native/*/build/
|
|
native/*/.fetchcontent-cache/
|
|
|
|
## scripts/run-physics-demo.sh copies the game-specific plugin's built
|
|
## output directly into its own folder (that's where its own pluginPaths
|
|
## entry in project.json points) — regenerated, not source. plugin.json,
|
|
## the .csproj, and the .cs files there stay tracked.
|
|
samples/*/GamePlugins/*/*.dll
|
|
samples/*/GamePlugins/*/*.pdb
|
|
|
|
## Windows builds of the native physics/audio shims — nothing here can
|
|
## build or verify one (no Windows machine), so unlike linux-x64's .so,
|
|
## win-x64's .dll is never committed. .github/workflows/build.yml's
|
|
## Windows job builds it fresh into this exact path before `dotnet build`.
|
|
**/native/win-x64/
|