| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
The OpenCOLLADA package contains a mix of files with unix and dos line endings.
Now we mark the diff as a binary file so that the patch also contains a mix of
line endings that matches the package.
|
|
|
|
|
|
|
|
|
|
|
|
Bringing Embree's motion blur closer to Cycles' native blur.
This requries Embree 3.8.0 or newer.
Differential Revision: https://developer.blender.org/D6575
|
|
Seems like sometimes files are being only partially ready, which makes it so there
are unsigned files, failing to deliver fully signed bundle.
Now expected archive file size is stored into stamp file and is checked against
size of the archive file on another side.
There are some bare prints used for debugging, would need to switch it to a proper
logger (or to be removed).
|
|
This extends FindOpenShadingLanguage.cmake to also look for the location of
stdosl.h and adds the path to the invocation of oslc to deal with the headers
being in different locations a little better.
Differential Revision: https://developer.blender.org/D6865
Reviewers: brecht
|
|
|
|
- Doesn't work
- If it worked, having a different CRT than the rest of
the process would not be a good thing.
|
|
No other default enabled libraries have an option either.
|
|
The default in Boost changed from global to hidden, but other libraries do
not use hidden symbols which gives warnings at link time on macOS.
|
|
Ref T73819, T73778
|
|
|
|
The latest versions of Embree allow similar motion interpolation
as Cycles' own BVH.
|
|
MSVC has a conformance mode (/permissive-) where the C++ standard is more strictly
enforced. This mode is available on MSVC 15.5+ [1]
This patch enables this mode on compilers that support it and cleans up the few violations it threw up in the process.
- Mantaflow was using M_PI without requesting them using the _USE_MATH_DEFINES define to opt in to non default behaviour.
- Collada did not include the right header for std::cerr, this seemingly was fixed for other platforms already but put inside a platform guard.
- Ghost had some scoping issues regarding uninitialized variables and goto behaviour
Second landing of this patch, earlier commit was reverted due to some compiler configurations having slipped though testing
[1] https://docs.microsoft.com/en-us/cpp/build/reference/permissive-standards-conformance
Differential Revision: https://developer.blender.org/D6824
Reviewed By: brecht
|
|
support it."
It is breaking compilation on some configurations, revert for now while
i see what is wrong.
This reverts commit 9fe469c110940af5d2525158305d5d365bd15276.
|
