detail::path_base() doesn't handle Linux path separators on Windows

[Robadob]

Was attempting to test whether a kernel with GLM would build with NVRTC (I'm not hopeful).

Ran into a failure, where all GLMs nested #include statements were failing to resolve.

glm/glm.hpp(105): warning: detail/_fixes.hpp: [jitify] File not found
glm/glm.hpp(107): warning: detail/setup.hpp: [jitify] File not found
glm/glm.hpp(114): warning: fwd.hpp: [jitify] File not found
glm/glm.hpp(116): warning: vec2.hpp: [jitify] File not found
glm/glm.hpp(117): warning: vec3.hpp: [jitify] File not found
glm/glm.hpp(118): warning: vec4.hpp: [jitify] File not found
glm/glm.hpp(119): warning: mat2x2.hpp: [jitify] File not found
glm/glm.hpp(120): warning: mat2x3.hpp: [jitify] File not found
glm/glm.hpp(121): warning: mat2x4.hpp: [jitify] File not found
glm/glm.hpp(122): warning: mat3x2.hpp: [jitify] File not found
glm/glm.hpp(123): warning: mat3x3.hpp: [jitify] File not found
glm/glm.hpp(124): warning: mat3x4.hpp: [jitify] File not found
glm/glm.hpp(125): warning: mat4x2.hpp: [jitify] File not found
glm/glm.hpp(126): warning: mat4x3.hpp: [jitify] File not found
glm/glm.hpp(127): warning: mat4x4.hpp: [jitify] File not found
etc

Added a breakpoint here to catch where detail::load_source() was being called.

Found these variable values

include_parent_fullpath = "C:/Users/Robadob/fgpu2/build/FLAMEGPU2/_deps/flamegpu2_visualiser-build/glm-src\\glm/glm.hpp" (Note that's an escaped \, not double)
include_path = "C:/Users/Robadob/fgpu2/build/FLAMEGPU2/_deps/flamegpu2_visualiser-build/glm-src"

This means that detail::path_base() is handling the path improperly.

The method is fairly simple

inline std::string path_base(std::string p) {
  // "/usr/local/myfile.dat" -> "/usr/local"
  // "foo/bar"  -> "foo"
  // "foo/bar/" -> "foo/bar"
#if defined _WIN32 || defined _WIN64
  char sep = '\\';
#else
  char sep = '/';
#endif
  size_t i = p.find_last_of(sep);
  if (i != std::string::npos) {
    return p.substr(0, i);
  } else {
    return "";
  }
}

Seems quite clear that it's neglecting the fact that either path separator is supported under Windows (as far as I understand).

Should be an easy fix, I'll make a PR soon.

Edit: According to people on StackOverflow, MSVC used to require backslash, but now it doesn't care. Unclear when that requirement was lifted, regardless I don't expect it will affect NVRTC.

[Robadob]

Was attempting to test whether a kernel with GLM would build with NVRTC (I'm not hopeful).

With the fix from #88, get a bit further.

---------------------------------------------------
--- JIT compile log for inputdata_program ---
---------------------------------------------------
detail/setup.hpp(695): error: namespace "std" has no member "make_unsigned"

detail/func_common.inl(585): error: namespace "std" has no member "isnan"

detail/func_common.inl(624): error: namespace "std" has no member "isinf"

detail/func_common.inl(742): error: namespace "std" has no member "fma"

4 errors detected in the compilation of "inputdata_program".

I've managed to fix the 3 cuda math intrinsics with a small patch to GLM, that will hopefully be merged (g-truc/glm#1073).

make_unsigned is template magic from the type_traits header that Jitify probably needs to implement. This is only a low priority thing to me, so I'll try and remember to look into adding that to Jitify's type_traits shim in future (it's marked as 'highly incomplete', so won't bother with an issue).