Page MenuHome

Cmake/deps: Update OSL to 1.11.10.0
ClosedPublic

Authored by Sybren A. Stüvel (sybren) on Jan 26 2021, 4:24 PM.

Details

Summary

This resolves T83631

sometimes bumping a version is just editing versions.cmake and that's it, this howerver is not one of those cases, OSL made some rather significant changes to their build system (for the better) and turned the previous soft dependency on clang now a hard dependency (they dropped boost wave support) which snowballed a little into other deps.

OSL Expects clang/llvm to live in a single folder, convincing OSL that is not the case seems more work than actually making clang/llvm build together so this is addressed as well.

Included in this diff:
-OSL Update to 1.11.10.0
-refactor the llvm/clang/clang-tools-extra builds into the llvm build using the llvm-project tarball for building that has all of the subprojects in it.
-update ispc/openmp builds since clang no longer its own dependency and they have to depend on the llvm build now.
-Update the windows builder to use the 64 bit host tools since it ran out of ram linking clang
-Since OSL now needs clang to link successfully a findclang.cmake has been provided for linux/mac, I know for sure it links blender on linux at this point, it may or may not need additional tweaks to build/link D9465 and/or mac.

I'm somewhat divided on combining all of this into a single diff, they seem independend things, on the other hand they are also fully dependend on each other, and you cannot roll back one without having to roll back all others as well, so for that reason I have combined all into a single diff

builds and passes all tests on both windows and linux, was not able to test on mac, and I'm not entirely sure I didn't make any mistakes in the refactor of clang-tools-extra (which only builds on mac) so mac maintainers keep an eye on that!

review/test only at this point, landing may be a little tricky, keeping it all in one diff makes sense, however landing the clang stuff first would make things a lot eaiser though.. still torn there..

Note: There is a boost update in T83246: VFX Reference Platform 2021 Compatibility so this should be landing after that to prevent multiple updates of the same lib

Diff Detail

Repository
rB Blender
Branch
tmp_osl (branched from master)
Build Status
Buildable 12394
Build 12394: arc lint + arc unit

Event Timeline

Ray Molenkamp (LazyDodo) requested review of this revision.Jan 26 2021, 4:24 PM
  • Fix missing headers on windows.
CMakeLists.txt
419

Needs to be added to config files in build_files/cmake/config/blender_*.cmake

build_files/build_environment/cmake/llvm.cmake
30

Need to set BUILD_CLANG_TOOLS to ON.
Or change the check in harvest to APPLE

build_files/cmake/Modules/FindClang.cmake
26

lower case clang in /opt/lib/CLANG

94

Lower case Clang. It'll create name mismatch warnings otherwise.

Brecht Van Lommel (brecht) requested changes to this revision.Feb 1 2021, 8:19 PM

osx_locals.map and blender.map probably need to be updated to hide clang symbols (unless they are in the llvm namespace?). I can help with this but no time today.

CMakeLists.txt
419

WITH_CLANG needs to be enabled below the line # auto enable llvm for cycles_osl, otherwise it gives a link error.

That mechanism could be changed to something more consistent with how we handle other dependencies, but easiest is to just follow we have we for WITH_LLVM.

build_files/cmake/Modules/FindClang.cmake
86

Remove debug print.

This revision now requires changes to proceed.Feb 1 2021, 8:19 PM
Ray Molenkamp (LazyDodo) marked 6 inline comments as done.
Ray Molenkamp (LazyDodo) edited the summary of this revision. (Show Details)
  • Updates with feedback
  • Merge remote-tracking branch 'origin/master' into tmp_osl
This comment was removed by Ray Molenkamp (LazyDodo).

Hide Clang symbols. It uses the clang:: namespace, so do the same as we did for hiding llvm:: symbols.

This revision is now accepted and ready to land.Feb 2 2021, 3:58 PM

Fine from my side. Builds correctly on Linux and Cycles OSL tests pass.

Cleanups: fix CMake name mismatch warning, lower case for functions, fix typos, use info_cfg_option.
No functional change.

Please remember to include install_deps (and ideally, to first create a task for such lib updates)... Annoying to always get that kind of info by random other tasks/topics.

I generally make those tasks when i'm actually expecting the other platform devs to start landing the libs which is not the case just yet here.

Sybren A. Stüvel (sybren) requested changes to this revision.Feb 16 2021, 12:58 PM

Apparently OSL stores the *.h files for the shaders in a different directory now (shaders/*.hshare/OSL/shaders/*.h). I needed this addition to the patch for the harvesting step to pick them up.

I didn't need anything extra to build Blender itself against the upgraded OSL.

diff --git a/build_files/build_environment/cmake/harvest.cmake b/build_files/build_environment/cmake/harvest.cmake
index b1686a75eaf..722b8ec5630 100644
--- a/build_files/build_environment/cmake/harvest.cmake
+++ b/build_files/build_environment/cmake/harvest.cmake
@@ -157,7 +157,7 @@ harvest(xr_openxr_sdk/lib xr_openxr_sdk/lib "*.a")
 harvest(osl/bin osl/bin "oslc")
 harvest(osl/include osl/include "*.h")
 harvest(osl/lib osl/lib "*.a")
-harvest(osl/shaders osl/shaders "*.h")
+harvest(osl/share/OSL/shaders osl/share/OSL/shaders "*.h")
 harvest(png/include png/include "*.h")
 harvest(png/lib png/lib "*.a")
 harvest(pugixml/include pugixml/include "*.hpp")
This revision now requires changes to proceed.Feb 16 2021, 12:58 PM
This revision is now accepted and ready to land.Feb 16 2021, 2:39 PM
  • CMake/deps: OSL, harvest new shader directory
  • CMake/deps: Updates and cleanups to build OSL on macOS

@Sybren A. Stüvel (sybren) @Ray Molenkamp (LazyDodo) Are DOPENEXR_HOME, DILMBASE_HOME and DLLVM_ROOT needed on Windows / Linux?
On macOS they were just unused variables.

I added DOPENEXR_ROOT, DILMBASE_ROOT and DLLVM_DIRECTORY.

build_files/build_environment/cmake/osl.cmake
71

Duplicate option -DBUILD_SHARED_LIBS=OFF

@Sybren A. Stüvel (sybren) A. Stüvel (sybren) @Ray Fonk (ray) molenkamp (LazyDodo) Are DOPENEXR_HOME, DILMBASE_HOME and DLLVM_ROOT needed on Windows / Linux?

They were in the past, unsure if they are still needed currently, given how badly this diff snowballed, i just wanted it to be over and didn't do much cleanup

build_files/build_environment/cmake/osl.cmake
71

Ah, that was the unused DBUILDSTATIC ..

  • CMake/deps: Removed duplicate shared libs variables

This patch no longer applies to master, as rBae370e292af2f7092db02301e9deb6dd9d7a1441 also modified LLVM. I'll see if I can merge the changes.

Oh, the upgrade to llvm 11 in that commit will most likely break the OSL build on macOS arm ... @Ray Molenkamp (LazyDodo) this is not over yet :)

Rebase on master, merging in the macOS changes. @Sebastián Barschkis (sebbas) I'm expecting this to break macOS, can you check?

The update to llvm was only for mac/arm64 should have left all other platforms intact ?

@Sybren A. Stüvel (sybren) On macOS x86 it builds just fine. For macOS arm I can test next week (I am fairly certain there will be a problem with OSL C++11 and LLVM 11).
What about ILMBASE_HOME, OPENEXR_HOME and LLVM_ROOT? Can they be removed? (also @Ray Molenkamp (LazyDodo))

The update to llvm was only for mac/arm64 should have left all other platforms intact ?

It did, but this patch changes from "llvm-only" to "llvm-project", which I also blindly applied to the macOS conditional code in versions.cmake. This means I changed macOS-specific stuff without any testing.

as for the cleanup i'll have to once more build it and check, i'll have an answer over the weekend

  • OSL CMake parameters updated

What about ILMBASE_HOME, OPENEXR_HOME and LLVM_ROOT? Can they be removed? (also @Ray Molenkamp (LazyDodo))

There have been some case changes. I get warnings that ILMBASE_HOME and OPENEXR_HOME are unused, but I also get these warnings:

-- Could NOT find Imath (missing: Imath_DIR)
-- Could NOT find IlmBase (missing: IlmBase_DIR)
-- Could NOT find OpenEXR (missing: OpenEXR_DIR)

I can't get it to find Imath though, even when I add -DImath_ROOT=${LIBDIR}/openexr/ it complains it can't find it. Builds fine without it, though.

Looking at the CMake output, it also complains that it can't find Qt5 files. We may want to add -DUSE_Qt5=OFF to prevent accidentally linking to Qt when they happen to be available on the system.

I've updated the patch for all of the above.

I can't get it to find Imath though, even when I add -DImath_ROOT=${LIBDIR}/openexr/ it complains it can't find it. Builds fine without it, though.

You can ignore that, took a closer look, Imath has been moved to its own package in 3.x it tries to find that first, if that fails it tries a few 2.x based strategies where it lives with the rest of openexr

current diff seems to build ok for me.

Builds fine on macOS, let's get this in!

This revision was automatically updated to reflect the committed changes.