| Age | Commit message (Collapse) | Author |
|---|
|
Static tbb has always been frowned upon [1] sofar it has worked for us but
given our reliance on tbb is about to increase (D7475), I'd like to move the library
to more supported configuration. Which means moving it to be a dynamic library
The libs part of this change is in rBL62416
Reviewed By: Brecht
Differential Revision: https://developer.blender.org/D7570
|
|
This diff add supports for crash logs on windows for
release builds. This can be toggled on/off with the
`WITH_WINDOWS_PDB` cmake option. by default it is on.
Things to take into consideration:
Release builds are hightly optimized and the resulting
backtraces can be wrong/misleading, take the backtrace
as a general area where the problem resides rather than
an exact location.
By default we ship a minimized symbol file that can only
resolve the function names. This was chosen to strike
a balance between growth in size of the download vs
functionality gained. If more detailed information is
required such as source file + line number information
a full pdb can be shipped by setting `WITH_WINDOWS_STRIPPED_PDB`
to off.
Differential Revision: https://developer.blender.org/D7520
Reviewed by: brecht
|
|
Matches WITH_GHOST_{SDL|WAYLAND}
|
|
Issues with older cmake.
|
|
Partial revert of D7520
|
|
This diff add supports for crash logs on windows for
release builds. This can be toggled on/off with the
`WITH_WINDOWS_PDB` cmake option. by default it is on.
Things to take into consideration:
Release builds are hightly optimized and the resulting
backtraces can be wrong/misleading, take the backtrace
as a general area where the problem resides rather than
an exact location.
By default we ship a minimized symbol file that can only
resolve the function names. This was chosen to strike
a balance between growth in size of the download vs
functionality gained. If more detailed information is
required such as source file + line number information
a full pdb can be shipped by setting `WITH_WINDOWS_STRIPPED_PDB`
to off.
The Release in the title of this diff refers to the
release build type, not the official blender releases.
Initially this will only be enabled for nightly build
bot versions of blender, official releases as of now
will not ship with symbols.
Differential Revision: https://developer.blender.org/D7520
Reviewed by: brecht
|
|
This patch enables TBB as the default task scheduler. TBB stands for Threading Building Blocks and is developed by Intel. The library contains several threading patters. This patch maps blenders BLI_task_* function to their counterpart. After this patch we can add more patterns. A promising one is TBB:graph that can be used for depsgraph, draw manager and compositor.
Performance changes depends on the actual hardware. It was tested on different hardwares from laptops to workstations and we didn't detected any downgrade of the performance.
* Linux Xeon E5-2699 v4 got FPS boost from 12 to 17 using Spring's 04_010_A.anim.blend.
* AMD Ryzen Threadripper 2990WX 32-Core Animation playback goes from 9.5-10.5 FPS to 13.0-14.0 FPS on Agent 327 , 10_03_B.anim.blend.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D7475
|
|
Usable with the CMake option 'WITH_GHOST_WAYLAND'
The following functionality is working:
- Building with X11 and Wayland at the same time,
wayland is used when available.
- Keyboard, pointer handling.
- Cursor handling.
- Dedicated off-screen windows.
- Drag & drop.
- Copy & paste.
- Pointer grabbing.
See D6567 for further details.
|
|
|
|
issue introduced in rB55a2682348df94d0ff2f57d786b7a557312d0345
|
|
Found by failing bundled modules test. The bz2 library was compiled without
proper minimum SDK version flags.
|
|
|
|
Add root usd library directory to build arguments, same as other libraries.
Also fix error/typo in compile_USD regarding _is_building.
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D7563
|
|
Can give considerably faster linking, especially for debug builds.
This may be enabled by default but needs to be more thoroughly tested.
|
|
sccache [1] is one of the few ccache like solutions that will
work on windows.
sccache support can be enabled with the `WITH_WINDOWS_SCCACHE`
cmake option however it will only will work with ninja as the
build system, msbuild is not supported currently.
Advanced option, developes are expected to obtain and configure
sccache on their own.
```
Full build no cache 1428.90s (100.00%)
Full build cached 434.34s ( 30.40%)
```
[1] https://github.com/mozilla/sccache
Reviewed By: nicholas_rishel, Brecht
Differential Revision: https://developer.blender.org/D7466
|
|
Otherwise file browsers do not recognize the Blender executable. This is
already done for official releases.
We leave it off for non-portable builds, since that's how Linux distribution
packages will typically build Blender and we can continue to follow the OS
default there. Using a file browser to launch executables from e.g. /usr/bin
would be rare as wel.
Differential Revision: https://developer.blender.org/D7363
|
|
Path to the jsons was wrong so they were not copied
|
|
Following up to b555b8d.
Building Blender with hidden symbols but using libraries with visible symbols
was giving linker warnings, specifically for USD. So revert that for now, as
it was not needed for the bugfix.
Hide USD symbols (some of which are not in the USD namespace) to avoid potential
conflicts. May potentially help with AMD OpenCL issues in T74262.
|
|
|
|
On macOS this is part of the collada folder, but for Linux xml2 is in its own
folder for precompiled libraries.
|
|
Differential Revision: https://developer.blender.org/D7309
|
|
Ref D7309
|
|
Inspired by @mrwhite in D7295
|
|
This means symbols from Blender itself and most external libraries. We can't
just hide all because that breaks some libraries. The better solution would
be to rebuild all library dependencies with hidden visibility.
Fixes T75223: Luxrender add-on failing to load on macOS
|
|
This is annoying when one want to use system python and hence disables
the `WITH_PYTHON_INSTALL` options...
|
|
Update for D3078, I think it should be fixed
Benefits:
- after installing python 3.7 with `./build_files/build_environment/install_deps.sh`, user will be able to run `make bpy` without linking error:
- https://blender.stackexchange.com/questions/102933/a-working-guidance-for-building-blender-as-bpy-python-module
- https://stackoverflow.com/questions/36779834/compiling-blender-bpy-recompile-with-fpic
To prevent errors like `/opt/lib/python-3.7.4/bin/python3.7: error while loading shared libraries: libpython3.7m.so.1.0: cannot open shared object file: No such file or directory`, add python .so lib to ldconfig
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D7177
|
|
Need to give correct SDKROOT.
|
|
The spelling should match exactly between how package is called in
find_package and in FIND_PACKAGE_HANDLE_STANDARD_ARGS.
|
|
Happens on macOS 10.15.4 and Xcode 11.4.
The reason of failure is caused by following factors:
- xcodebuild reports full semantic macOS SDK version 10.15.4
- The actual SDK file path will only include major and minor part
of the version (10.15, MacOSX10.15.sdk)
- Previous CMake code of ours expected direct match between SDK
version and file path.
The solution is to make our detection code a bit more flexible and
additionally check for major.minor macOS SDK version in the path.
|
|
The specific goal of this change is to get rid of separate code paths
for older and newer Xcode versions.
The version 8.2 is picked since it's the latest version which runs on
macOS 10.11 (which is our current deployment target). If that turns
out too new for some reason the alternative would be to require Xcode
version 5.
|
|
The main CMakeLists already requires CMake 3.5, so there is no point of
requiring "newer" CMake on macOS.
This was a code from a while back where CMake 3 was not required on all
platforms.
|
|
Legacy code did not take into account the fact that major version can
be two digits. This was causing "Xcode 11.4" to be detected as "11.".
|
|
VS2015 has not been supported for a while now but make.bat
still had some support for it.
|
|
As a result the MD5sum of the downloaded package also changed.
|
|
Force the SDK to use its own, bundled JsonCpp sources.
|
|
|
|
|
|
|
|
- Harvest to a proper location.
- Disable STD's filesystem which is experimental and caused
linking errors when OpenXR is usedi n Blender.
|
|
Allows to have 2.82a as a beta version on buildbot.
|
|
Should be `XR_OPENXR_SDK_ROOT_DIR`.`
|
|
The OpenXR-SDK contains utilities for using the OpenXR standard
(https://www.khronos.org/openxr/). Namely C-headers and a so called
"loader" to manage runtime linking to OpenXR platforms ("runtimes")
installed on the user's system.
The WITH_XR_OPENXR build option is disabled by default for now, as there
is no code using it yet. On macOS it will remain disabled for now, it's
untested and there's no OpenXR runtime in sight for it.
Some points on the OpenXR-SDK dependency:
* The repository is located at
https://github.com/KhronosGroup/OpenXR-SDK (Apache 2).
* Notes on updating the dependency:
https://wiki.blender.org/wiki/Source/OpenXR_SDK_Dependency
* It contains a bunch of generated files, for which the sources are in a
separate repository
(https://github.com/KhronosGroup/OpenXR-SDK-Source).
* We could use that other repo by default, but I'd rather go with the
simpler solution and allow people to opt in if they want advanced dev
features.
* We currently use the OpenXR loader lib from it and the headers.
* To use the injected OpenXR API-layers from the SDK (e.g. API
validation layers), the SDK needs to be compiled from this other
repository.
The extra "XR_" prefix in the build option is to avoid mix-ups of OpenXR
with OpenEXR.
Most of this comes from the 2019 GSoC project, "Core Support of Virtual
Reality Headsets through OpenXR"
(https://wiki.blender.org/wiki/User:Severin/GSoC-2019/).
Differential Revision: https://developer.blender.org/D6188
Reviewed by: Campbell Barton, Sergey Sharybin, Bastien Montagne, Ray
Molenkamp
|
|
|
|
Recent refactor external dependencies handling (D6642)
improperly linked all library dependencies with public
linkage rather than interface linkage. Causing excessive
(re)builds of subprojects when not needed.
This patch restores the interface linkage.
Reviewed By: brecht sergey
Differential Revision: https://developer.blender.org/D6983
|
|
And other code tweaks to make this library more consistent with others.
Differential Revision: https://developer.blender.org/D6864
|
|
System GLEW often is not new enough, which gives error on startup. The build
correctness should not be affected by using lite vs. full, so better to leave
this out than save compiling one extra file.
|
|
This will more important when we start using OpenVDB in more modules.
|
|
On Linux, precompiled libraries may be made with a glibc version that is
incompatible with the system libraries that Blender is built on. To solve
this we add a few -ffast-math symbols that can be missing.
Differential Revision: https://developer.blender.org/D6930
|
|
Based on work by Nathan Craddock, with further changes to apply it to all
precompiled libraries.
Differential Revision: https://developer.blender.org/D6929
|
|
Lots of fixes and cleanups, mainly addressing:
* OpenEXR building was fully broken.
* Missing dependencies of Alembic to Boost and openEXR.
* OSL had changed its CMake parameters for custom OpenEXR install path.
* Dependencies between libs were not properly handles when switching a
lib from own build to system package.
|
