We will upgrade the macOS minimum version to 10.13. I will make that change shortly along with related changes for the precompiled libraries.

There's an issue on macOS that multiple devs stumbled over now, bcf49d13e534. To address that we'd have to drop support for macOS 10.12 and 10.13 from what I can tell.

After discussion with Sergey, we decide not to upgrade the external libraries to C++14, and instead go directly to C++17 in about 6 months from now when we upgrade to VFX reference platform 2021.

Just thought I should mention @Ray molenkamp (LazyDodo)'s D8126 here.

embree is done, tbb got added when i took out the erroneous exports, oidn still needs to be done indeed.

I believe we are now ready with the CMake builder updates for 2.90, and that we can do the precompiled library updates now.

Hi! please use svn precompiled libraries as mentioned at https://wiki.blender.org/wiki/Building_Blender/Linux/Ubuntu#Quick_Setup

mkdir ~/blender-git/lib
cd ~/blender-git/lib
svn checkout https://svn.blender.org/svnroot/bf-blender/trunk/lib/linux_centos7_x86_64

For build issues, please ask on https://devtalk.blender.org/c/blender/building-blender/11

In T77813#958440, @Germano Cavalcante (mano-wii) wrote:

This report is already getting very confusing.
A lot of pertinent information is scattered in the comments.
And I'm not sure which to look at first.

This is too time consuming for us to track down and we require the bug reporter to narrow down the problem.

This report is already getting very confusing.
A lot of pertinent information is scattered in the comments.
And I'm not sure which to look at first.

Just tested this issue under my Archlinux/KDE installation with blender installed from official Arch repo (blender 17:2.83-1), do the exact same steps, and also can reproduce this issue.

To reproduce this issue, we need a clean environment with blender 2.83 just installed. I use the zip version instead of the installer. The reproduce steps:

False alarm. (I mistook "Save Startup File" for "Save preferences")

I can confirm with the official version of blender 2.80, installing through the installer (not the zip)

• CTest integration via the gtest_discover_tests() command.

I would like to see Python upgraded to 3.7.7, as there have been a bunch of security fixes.

That or use a naming convention so every test in a file starts with the same prefix, but that's a bit fragile.

In D7649#192868, @Sybren A. Stüvel (sybren) wrote:

• Each test invocation then has to load the same binary. I expect this to be potentially quite slow, as it can be 1.5 GB in debug mode. Loading that binary once and then running all tests will probably be faster, although it does increase the chance of one test influencing the test (as they'd then all run in the same process) and would prevent running the tests in parallel.

In D7649#192724, @Brecht Van Lommel (brecht) wrote:

I was expecting the tests to remain individual ctests instead of all being part of one Blender ctest, invoking blender_tests multiple times with different --gtest_filter arguments.

In D7649#192674, @Sybren A. Stüvel (sybren) wrote:

I think it's nice to have the tests in the same namespace as the code under test. It could be in the global namespace too and have a using blender::module; statement at the top. I don't have strong feelings about this one.

• Setup libdirs and liblinks as per Brecht's diff.
• Add include(GTestTesting) to intern/libmv/CMakeLists.txt to get libmv building again.
• Add buildinfo to the blender_test executable.

This patch does not pass the CMake step for me either, afaict it's missing the BLENDER_SRC_GTEST entirely?

I had to disable WITH_LIBMV to even get it through cmake

I had to add this to make it build, but I guess this is still work in progress (and not integrated with ctest?).

diff --git a/tests/gtests/CMakeLists.txt b/tests/gtests/CMakeLists.txt
index 68a44b28817..90f610899b1 100644
--- a/tests/gtests/CMakeLists.txt
+++ b/tests/gtests/CMakeLists.txt
@@ -21,9 +21,13 @@ if(WITH_GTESTS)
   endif()
   unset(_test_libs)

• Updated namespaces

• Moved BLENDER_GFLAGS_NAMESPACE/GFLAGS/GLOG defines away from global scope. This does add to the duplication between blender_add_test_lib and BLENDER_SRC_GTEST_EX, so I can look into that later.
• Removed gtests_runner.{cc,h} as these were actuall needed for running the tests from Blender itself.
• Moved remove_strict_flags() into GTestTesting.cmake
• Added some clarifying comments

Please ignore the exact namespace in the test files for now. What I do want to have feedback on, is whether the test should be in:

the same namespace as the code under test,
in a tests sub-namespace, or
in an anonymous sub-namespace.

For the namespace question: I think it should be tests sub-namespace of what's being tested. For example, blender::depsgraph::tests.
When some helpers are needed use anonymous namespace inside of the tests.

I have updated D7649 with what was discussed above.

This is great news. Would really appreciate if this fix make it to the next 2.83 LTS release!

Thx to @Clément Foucault (fclem), also here it's works fine 👍

If I had symlinked the compilers, this would not have been an issue.
But such scripts fit my purpose so I'd rather move lib/clang folder for my use.

(app versions below)

I couldn't reproduce this problem with Xcode 11.0 and CMake 3.14.1.

That's good news :)
Thanks to @Clément Foucault (fclem)

Fixed! Works beautifully now. Finally usable on OSX thanks to everyone’s hard work.

I agree, unfortunate typo

Some improvements have been made in this area.
Can anyone confirm if this problem was fixed in the latest builds?
https://builder.blender.org/download/

So as noted in comment in rB60bed34f165b, FFMPEG 4.3.2… does not yet exist. Looks like it should be 4.2.3?

I've pretty much picked off the easy bits, the ones still open are linux only, and USD which needs changes to the integration code, @Sybren A. Stüvel (sybren) mind taking this one on linux? once the build issues in blender are taken care of i'll do the windows libs.