Yeah there used to be a button for to merge main but that appears to have gone awol in one of the gitea updates, if you could merge main manually, i'll give it another go on the bots
Not super thrilled about updating things just since it's nice to have a newer version, if it solves an actual bug, or resolves a security issue it's a different story though, however the last…
Neat find! Thanks! I'd actually prefer this way, at-least we'll know for sure we'll find a compatible openmp rather than some random version that happens to be in the registry, I suggest removing registry based method all together in favour of this.
Sorry that's still a no for me, i'd like to see no changes/dependencies on any files inside build_files/build_environment the information in there just isn't reliable and may not be in sync with…
The version information inside build_files/build_environment cannot be relied on from inside the blender build tree, while it is the version we desire to ship, there's no guarantee that is…
beyond that one small comment nitpick i got nothing either, just fix it before landing
This doesn't work, the CMake project in build_files/build_environment and the main CMakeLists for the blender project are not related, the versions in this file have to remain there.
I am aware this was likely copy/pasted from my initial stab, but I feel some non optional targets will likely make it into this file as well at one point, I'd drop optional from this comment for that reason.
Didn't test all formats but, saving the default cube at 1080p
Someone will have to take a closer look, gut feeling says It's likely a latency/iops related issue, I suspect the fast formats likely do fewer large writes while the slower formats do frequent…
- No idea, this could be diagnosed by running
msiexec /i blender-4.2.0-windows-x64.msi /l* blender.logand looking at the generated blender.log
2+3. The store version will use a sandboxed…
I'd probably place just the add_definitions(-DNOMINMAX) back where they went missing but use the new target for everything else, as to not upset things too much and deal with a min/max cleanup…
intern/mikktspaceseems fine to changeintern/mantaflowdoesn't use TBB just does the work so the headers from extern/mantaflow don't throw a fitextern/mantaflowuses-DTBB=1…
-DNOMINMAX went missing here, which may come back to haunt you, my plan was to add this define to the platform flags so all files would have it, but have not done so since some warns popped up about double defines in places that also tried dealing with this problem themselves, which i had no time to resolve just yet.
can't this just depend on bf::dependencies::optional::tbb ? ideally there should be no more instances of ${TBB_INCLUDE_DIRS} and ${TBB_LIBRARIES} through out our cmakefiles, except for the file that defines the ``bf::dependencies::optional::tbb` target