Reach vendored GLM via -I flags instead of include_dirs (avoids hipify mutating GLM headers)

[bjoernellens1]

PR draft: reach vendored GLM via -I flags instead of include_dirs (ROCm build)

Problem

The ROCm branch of get_extensions() in setup.py builds an include_dirs
list for the HIP build that never contains the vendored
gsplat/cuda/csrc/third_party/glm submodule path at all — unlike the CUDA
branch a bit further down in the same file, which already has glm_path as
the first entry of its own include_dirs. Every cxx and hipcc
invocation on the ROCm path fails with:

glm/gtc/type_ptr.hpp: No such file or directory

Why the obvious fix fails

The obvious fix is to just add glm_path to the ROCm branch's
include_dirs, mirroring the CUDA branch. That resolves the "file not
found" error, but breaks the build a different way.

CUDAExtension() forwards its include_dirs kwarg straight into
torch.utils.hipify.hipify_python.hipify(header_include_dirs=include_dirs).
That call walks every header reachable from those directories and rewrites
CUDA-specific tokens in place — not just in gsplat's own sources, but in
anything sitting under an include_dirs path, including a vendored
third-party submodule that has nothing to do with CUDA/HIP itself.

Concretely, hipify's token rewriting touches glm/simd/platform.h's own
compiler-detection macros. Among other substitutions, it flips
__CUDACC__ → __HIPCC__. That trips glm's
#elif defined(__HIPCC__) branch before glm's real
#elif defined(__HIP__) branch is reached, so glm concludes it is being
compiled by an unversioned CUDA compiler and aborts with:

GLM requires CUDA 7.0 or higher
GLM_COMPILER undefined

which cascades into "no matching function" errors on every glm::mat/vec
call in the HIP kernels. This is confirmed by diffing the glm submodule
after a build (git -C third_party/glm diff shows the mutation in
platform.h when glm_path sits in include_dirs).

Note this is one of potentially several substitutions hipify makes inside
platform.h while walking the directory — the root cause is that hipify is
walking and mutating vendored third-party headers at all, not any single
token it happens to rewrite. A fix that keeps glm out of hipify's
header_include_dirs scan avoids all of them at once, rather than patching
around individual token collisions as they're discovered.

Fix

Leave glm_path out of include_dirs on the ROCm branch (so hipify never
walks it) and instead pass it as an explicit -I flag on both
extra_compile_args["cxx"] (plain .cpp sources) and hipcc_flags
(aliased into extra_compile_args["nvcc"], which is the flag list actually
used for the .hip compile path via hipcc). Both compile paths resolve
glm's real, unmutated headers this way, since -I flags only reach the
compiler invocation and are never passed to hipify's directory scan.

glm_include_path = osp.join(
    current_dir, "gsplat", "cuda", "csrc", "third_party", "glm"
)
extra_compile_args["cxx"] += [f"-I{glm_include_path}"]
hipcc_flags += [f"-I{glm_include_path}"]

Verification

A full pip install run produces zero glm/gtc/type_ptr.hpp: No such file
and zero GLM requires CUDA errors on gfx1151. Confirmed via
git -C gsplat/cuda/csrc/third_party/glm diff showing no mutation of the
submodule after a build with this change in place. The build proceeds past
glm entirely and continues to the actual kernel compilation.

Relevance to #17

#17 also touches GLM/HIP plumbing (adding glm_path to include_dirs plus
-DTORCH_HIP_VERSION=8000 to satisfy glm's now-hipified
CUDA_VERSION-based version gate). That's addressing a real, separately
observed symptom of the same underlying cause: hipify rewriting tokens
inside the vendored glm headers because they sit under include_dirs. The
-I-flag approach here sidesteps that class of problem at the root — glm
is never handed to hipify's walk at all, so no downstream -D workaround
is needed to compensate for whatever it rewrites.

Happy to have this folded into #17 directly if that's preferred, since it
touches the same lines, or opened as its own small standalone PR if #17's
author would rather keep the two concerns separate — whichever is easier to
review.