CMake: prefer the vendored simdjson include path

[tomjn]

What

Add BEFORE to the include_directories() call for the vendored simdjson so the in-tree rts/lib/simdjson/include always leads the include search path.

Why

On macOS, locating DevIL via Homebrew (find_package_static(DevIL)) pulls /opt/homebrew/include onto the global include path. A Homebrew-installed simdjson sitting there can shadow our vendored, version-matched copy and break the build — a newer simdjson trips an AppleClang macro collision. Prepending the vendored directory guarantees <simdjson.h> resolves in-tree on every platform.

This is a pure ordering change: it only moves the vendored directory to the front of the include search. Where no Homebrew simdjson is present (Linux/Windows CI) it is a no-op.

Source

Extracted from ExaDev/RecoilEngine commit 806d539 ("prefer vendored simdjson over Homebrew leak via include BEFORE").

Testing

• Reconfigured cmake -S . -B build-macos-headless on macOS (arm64, Homebrew gcc-16, RelWithDebInfo) — clean configure.
• Inspected the generated compile command for a real consumer (rts/Rendering/Models/GLTFParser.cpp) and confirmed -I.../rts/lib/simdjson/include precedes /opt/homebrew/include in the include search order.

AI usage disclosure

This change was prepared with AI assistance (Claude Code): the assistant located the include line, adapted the upstream comment to match master's context, made the edit, and verified the configure and include ordering. The change was reviewed by a human before submission.

[n-morales]

This seems very brittle. This seems like an issue with DeVIL find package. Manually prepending certain paths breaks the abstraction that CMake provides here.

[tomjn]

This seems very brittle. This seems like an issue with DeVIL find package. Manually prepending certain paths breaks the abstraction that CMake provides here.

was this meant for another PR? This change has nothing to do with DeVIL and isn't hardcoding paths

[n-morales]

In your description you said that this problem was introduced by DevIL find package bringing in the homebrew prefix. That seems like the issue here.

[tomjn]

Oh, so this would have been an issue eitherway it's just the DevIL was what threw it up. I'm not sure how this is any different from globally installed libraries on Linux though, just that here I installed via homebrew on a mac, and technically if someone had used homebrew on linux they'd get the same problem.

Wouldn't we always want our local vendored library includes to always take precedence over system libraries?

[p2004a]

This include line should not exist in the first place. Every target that needs simd json must link simdjson::simdjson, that will pull correct flags for compilation and linking. That must also handle correctly header resolution.

If this line is needed, it means that some target is missing linking of simdjson::simdjson.