Allright, fair enough, if driver 32 comes out and it doesn't fix the issue, people are back to black cubes for blender versions that may not get any more maintenance releases, `if (ver0 >= 31)…
are there older versions we need to worry about?
if HIP is not found, then there is no need to look for HIP-RT.
That's a valid point, ideally the code around [here](https://projects.blender.org/blender/blender/src/branch/main/intern/cycles/c…
lgtm now, but hold off landing for campbell to accept (I really miss the blocking reviewers phab had)
i admit, nitpicking now, but python.exe could be @_PYTHON_BINARY@ so it would use python_d.exe here for a debug build.
This doesn't appear to be doing anything?
I couldn't get it to full work. Asking cmake to fill in
@PYTHON_EXECUTABLE@on Windows gives the literal generator for the python executable, not the actual path.
Yeah cmake is kinda…
HIP_LINKER_EXECUTABLE is a hip component, checking on it here leads to the following bizarre log when it can't be found:
this causes a whole bunch of .cpp files inside the final libdir, the root cause is when running the install phase of the hiprt project it does not install any of its own headers and build_files\build_environment\cmake\hiprt.cmake ends up pillaging the source folder to get them. this is not how that is supposed to work. This needs to be fixed in upstream hiprt.
Would you or @LazyDodo like me to also use it on Windows?
I didn't think it was worth the extra complexity, and the find was fine to me, but given campbell made you do the work for the other…
Does it work when you manually copy the python3.dll from "C:\Program Files\Blender Foundation\Blender 4.2\python3.dll" to `"C:\Program Files\Blender Foundation\Blender 4.2\4.2\python\bin\python…