| Age | Commit message (Collapse) | Author |
|---|
|
We now want to use fairly recent TBB (2018 at least?), so distro a bit
old will not have required package anymore...
Tested with Debian, other distro "should work" (c), but tests there are
much welcome! ;)
|
|
Was breaking up proper behavior of 'need to rebuild' checks for that
lib.
|
|
Not sure where that code was comming from, but it was breaking the
cleanup/update_deps logic...
|
|
|
|
We never deal with packages then, and only ever build (if we do
anything), no reason to make things more complicated than needed...
|
|
Previous code would forec built libs to always be rebuilt when one of
their deps was using a package. While this could be useful when said
package was actually updated, this generates way too much false
positives.
Now only rebuild a built lib when we actually switch from built to
package for one of its deps.
|
|
|
|
|
|
Ever since debug symbols were added for release builds the linker
has been on the chatty side about symbols being missing for our
binary libs.
There's currently no plans to supply those, so best for the linker
not to warn us about them.
|
|
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`.`
|
