Page MenuHome

Add macOS deployment target 10.9 / SDK 10.12 / libc++ libraries.

Authored by Brecht Van Lommel (brecht) on Oct 8 2016, 3:56 PM.



These are the CMake updates for new libraries built using the same system used on Windows. You just need to install a few homebrew packages and then run "make install", and it will create the library folder totally automated.

The plan is to commit the libraries in a new lib/darwin/ folder. They can be used when enabling WITH_CXX11, but you need to do a clean build to clear old stuff from the cache properly.

Xcode 8 + custom clang 3.5 with OpenMP is not currently working with the old or new libraries, we need clang 3.9 to be compatible with the 10.12 SDK headers. For that we might still add a clang 3.9 build to the library folder.

Diff Detail

rB Blender

Event Timeline

Brecht Van Lommel (brecht) retitled this revision from to Add macOS deployment target 10.9 / SDK 10.12 / libc++ libraries..
Brecht Van Lommel (brecht) updated this object.

Should we add the cmake based dependencies builder to a git submodule or something and host it on infrastructure ?

I am thinking that this might in the future almost replace all the binary libs in svn

I'm ok with moving the dependency builder into the infrastructure, however I do feel it is important to keep the binaries in svn available and the primary place for getting them for the following reasons:

  1. building them takes a long time, if we force new devs to build their own, it'll just drive them away
  2. not all projects are hosted on a 'stable' infrastructure servers go up, servers go down (sometimes for days on end, I had this issue with some of the ffmpeg/python deps during development, it's the reason download caching feature got implemented in the script)
  3. I'm busy enough as is helping people with the odd blender build problem, you can add 52 (!!) other projects on top of that that also need building ,but I'm definitely not going to support it.
  4. I prefer all devs to be working from the same set of binaries just from a QA perspective, what the devs work with are 100% the same libs as what is being used for the final build, no surprises

I agree with @LazyDodo (LazyDodo), we can host this on, and I want to keep binaries too for the reasons mentioned.

I'd be inclined to just put it in e.g. build_files/dependencies/ like, a submodule doesn't really help I think. There some inconsistencies with Blender's folder naming and CMake code styles which we might want to fix if this gets more closely integrated into Blender's build system.

The macOS building is a somewhat fragile, not ready to run on any system. It specifically requires Xcode 8, some homebrew libraries installed, and there will likely be conflicts if you already have some libraries installed on your system. So at this point it would still be intended for platform maintainers to run. If someone wants to improve that then why not, but personally I'm not interested in officially supporting users that run into build issues due to some specific system configuration.

Blender 2.7x still has 10.6.8 as minimum OS. Will we still be able to build that easily?

Blender 2.7x should continue building. We'd still keep around the darwin-9.x.universal libraries for as long as needed, and this patch has no effect by default, it only kicks in when you manually set WITH_CXX11=ON.

In the Blender 2.8 branch we'd remove the WITH_CXX11 option and enable C++11 always (once the Linux side is ready for that).

Being able to build on OS 10.9 would be great. Building the libs can be a latest-OS-latest-Xcode thing, but general Blender development should be more inclusive.

I keep a 10.9 drive, can boot into that for testing.

Right, Blender will continue building on 10.9 and with older Xcode too (unless I made a mistake somewhere that needs to be fixed).

Even the dependencies likely build on 10.9 with Xcode 8, or an earlier Xcode versions if you set a lower SDK version, but we wouldn't support end users trying to build dependencies.

This revision was automatically updated to reflect the committed changes.

Side note: the libraries are 343MB and compressing them to .tar.gz makes that 76MB.

But svn commit and checkout uses the full 343MB, while I would expect the svn server to use compression. Maybe we need to tweak SVNCompressionLevel on the, particularly for the Windows libraries which are gigabytes. It might also be an issue with my particular svn client (version 1.9.4) though.