Every time CMake is re-run, Xcode shows a popup asking if
user wants to manage schemes automatically or manually.
Building Blender wiki page recommends managing schemes automatically.
This change sets the default behavior to "automatically" and generates
the .xcscheme files while CMake is running, instead of hogging Xcode
later on. With tests enabled, the number of schemes is 203.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8820
CMake caches the location of the CRT runtime in the
MSVC_REDIST_DIR variable, and uses it to copy the required
dll's during the install phase.
This variable is only initialized when it does not exist.
Leading to issues when compiler updates are installed and
the compiler version slightly changes, cmake still looks
in the old location for the runtime and warns about the
files not existing.
This change fixes the issue by checking if the redist dir
exists and if not unsets it so InstallRequiredSystemLibraries
can have another go at figuring out where they live.
Remove the hack for library initialisation; this is no longer necessary
as the required information can be passed to the USD library after its
static initialisers have run.
This new approach is compatible with both the patched and original USD
library. This means that platform maintainers don't need to rebuild the
USD library until the next upgrade.
Manifest Task: https://developer.blender.org/T80320
Delete `hdf5.diff`, because it's no longer used. Since Blender 2.90 the
optional support for HDF5 has been dropped, but this file accidentally
wasn't deleted.
See 0102b9d47e and 0c38436227.
No functional changes.
This is for design task T67744, Boolean Redesign.
It adds a choice of solver to the Boolean modifier and the
Intersect (Boolean) and Intersect (Knife) tools.
The 'Fast' choice is the current Bmesh boolean.
The new 'Exact' choice is a more advanced algorithm that supports
overlapping geometry and uses more robust calculations, but is
slower than the Fast choice.
The default with this commit is set to 'Exact'. We can decide before
the 2.91 release whether or not this is the right choice, but this
choice now will get us more testing and feedback on the new code.
It is now possible to build against a shared embree library.
Before it was only possible to build against static Embree libraries.
Reviewed By: Brecht
Differential Revision: http://developer.blender.org/D8702
OSL requires RTTI to be off, this is done with the /GR- flag for
MSVC, however /GR is in the default CXX flags leading to warning
D9025 : overriding '/GR' with '/GR-'
which cannot be suppressed.
/GR is on by default and this flag is not required, so removing
it from the default CXX flags makes it possible later use /GR-
without generating warnings.
Add `-Wno-maybe-uninitialized` option to `CMAKE_CXX_FLAGS_RELEASE` and
`CMAKE_CXX_FLAGS_RELWITHDEBINFO` variables on GCC/Linux.
In Release builds GCC's `-Wmaybe-uninitialized` warning is unreliable,
and thus causes noise that can drown out other warnings. These warnings
are now silenced in release mode builds.a
Debug builds seem fine, so flags for debug builds are not touched by
this commit.
No functional changes.
Reviewed By: Sergey
Differential Revision: https://developer.blender.org/D8615
The description is self-explanatory: enable SSE optimizations in the
FFmpeg library. They were disabled from the very beginning of the
dependency builder, possibly due to portability concerns.
FFmpeg does perform runtime check for available CPU microarchitectures,
so the codecs will still run on older hardware, but they will run way
faster on newer hardware.
For example, re-encoding 3405 2560x1376 frames on Xeon E5-2699 V4 CPU
went down from 313sec to 210.
Differential Revision: https://developer.blender.org/D8594
By default boost::python in debug configuration links the release
python libraries. Which leads to loading issues with the produced
modules in a debug blender (which does use the debug python libs)
Bjam has an option to switch this to the debug libraries but when
you switch that on it changes the library names for *all* boost
libraries, even ones that don't have anything to do with python
and even the release libraries.
therefore an alternative way has been chosen and we're dealing
with this by adding a define rather than asking bjam to do it.
This patch changes openvdb from a static to a dynamic library.
this is in preparation for enabling pyopenvdb at some point
in the future.
Differential Revision: https://developer.blender.org/D8282
Reviewed by: brecht
This this adds the option of building boost::python
in the libs builder, in preparation for future
dependencies that require it (ie pyopenvdb)
disabled by default, can be enabled with the
`WITH_BOOST_PYTHON` cmake option.
Differential Revision: https://developer.blender.org/D8212
Reviewed by: brecht
This commits:
- Updates some libraries to latest officially supported versions:
** Numpy: 1.17.5
** OCIO: 1.1.1
** OIIO: 2.1.15
** OSL: 1.10.10
** OIDN: 1.2.1
- Re-enables some distro packages (like OSL, OIIO, OCIO...).
- Add missing 'CMake cleanup commands' for generated CMake update
command, for Embree, OIDN and OpenXR.
- Generalizes using min/max versions of accepted libraries, if no
package can be found in specified range then it is built from sources.
The later point should help keeping things a bit in better conditions,
although current maximal accepted versions are somewhat arbitrary guess
currently.
Fix package name missmatch in a few module files. IE "ALEMBIC" was
defined in the file but the find_package commands used "Alembic"
Some modules state that they set and use the _LIBRARY variable but the
do in fact not do this. Removed these comments from those files.
Required for the new boolean code, disabled by default
until all platforms have landed the libs and the boolean
code actually lands in master.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8384
Add our own copy of the gtest discovery scripts from CMake a few reasons:
* Use the very latest version which supports PRE_TEST for Windows
* Fix usage of [] symbols in file paths that fail with the zsh shell
* Disable asan leak checker when discovering tests
This means Windows also no longer requires the very latest CMake 3.18.
This bumps the minimum requirement for cmake from 3.10 to 3.18 on windows
if `WITH_GTESTS` is enabled.
Reviewed By: sergey brecht sybren campbellbarton
Differential Revision: https://developer.blender.org/D8405
Description of `USER_HEADER_SEARCH_PATHS` build setting:
"
This is a list of paths to folders to be searched by the compiler
for included or imported user header files (those headers listed
in quotes) when compiling C, Objective-C, C++, or Objective-C++.
Paths are delimited by whitespace, so any paths with spaces in
them need to be properly quoted. See Always Search User Paths
(Deprecated) (ALWAYS_SEARCH_USER_PATHS) for more details
on how this setting is used. If the compiler doesn't support the
concept of user headers, then the search paths are prepended to
the any existing header search paths defined in Header Search
Paths (HEADER_SEARCH_PATHS).
"
http://help.apple.com/xcode/mac/current/#/itcaec37c2a6
Xcode doesn't use `HEADER_SEARCH_PATHS` for auto-complete. Only the
header files in the same directory as the current file are suggested.
CMake as of now correctly sets `SYSTEM_HEADER_SEARCH_PATHS` and lumps the
rest in `HEADER_SEARCH_PATHS`. The standard way is to use
`USER_HEADER_SEARCH_PATHS` & `SYSTEM_HEADER_SEARCH_PATHS` and let
`HEADER_SEARCH_PATHS` be used as a fallback for compilers which do not
distinguish between `<*.h>` and `"*.h"` syntax.
So set `USER_HEADER_SEARCH_PATHS` to the include paths specified
in the `CMakeLists.txt` files of all targets.
In the situation where the precompiled libraries are used on Linux +
GCC, a version of GCC older than 9.3 is guaranteed to cause problems.
This just implents a fatal error message when we know it doesn't make
sense to continue. We could do more checks and add some warnings, but
it's very likely that these will be ignored amongst the other noise.
Reviewed By: sergey, brecht
Differential Revision: https://developer.blender.org/D8396
This patch changes the discovery of pre-compiled kernels, to look for any PTX, even if
it does not match the current architecture version exactly. It works because the driver can
JIT-compile PTX generated for architectures less than or equal to the current one.
This e.g. makes it possible to render on a new GPU architecture even if no pre-compiled
binary kernel was distributed for it as part of the Blender installation.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8332
This commit introduces a new way to build unit tests. It is now possible
for each module to generate its own test library. The tests in these
libraries are then bundled into a single executable.
The test executable can be run with `ctest`. Even though the tests
reside in a single executable, they are still exposed as individual
tests to `ctest`, and thus can be selected via its `-R` argument.
Not yet ported tests still build & run as before.
The following rules apply:
- Test code should reside in the same directory as the code under test.
- Tests that target functionality in `somefile.{c,cc}` should reside in
`somefile_test.cc`.
- The namespace for tests is the `tests` sub-namespace of the code under
test. For example, tests for `blender::bke` should be in
`blender::bke:tests`.
- The test files should be listed in the module's `CMakeLists.txt` in a
`blender_add_test_lib()` call. See the `blenkernel` module for an
example.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D7649
Enabling all `make deps` dependencies with the exception of Embree and OIDN.
After that, Blender can be compiled on an Apple Silicon Mac just like on any
Intel based Mac. There are still compiler warnings that need to be
investigated and there are probably a couple of bug still to be discovered
and to be fixed.
Most patches to the dependencies are simple and are about disabling SSE and
setting the proper architecture to compiile for. Notable exception is Python,
where I back ported a yet to be accepted PR for upstream Python:
https://github.com/python/cpython/pull/21249
Cross compiling or buliding a Universal Binary is not supported yet.
The minimum macOS target version for x86_64 remains at 10.13, the target
for arm64 is 11.00.
Differential Revision: https://developer.blender.org/D8236
There were two issues.
First is related on ISPC's CMake configuration forcing C and C++
compilers to be clang and clang++. This goes against of desired
behavior when we use our own compiled clang compilers.
The second issue was related on linker failure: CLang libraries
are linked statically, and they need some of C++ 11 STL symbols
which are coming from libstdc++.
Differential Revision: https://developer.blender.org/D8258
The ff_cfhd_init_vlcs() function was using a lot of stack space, which
made linker on macOS unhappy. Using heap allocation allows to silence
the warning without causing other side-effects.
Kept the patch enabled for all platforms to avoid difference in behavior
and performance on different platforms, which could make certain types
of investigation very tricky.
Differential Revision: https://developer.blender.org/D8248
C++17 does not work on 10.12, and Apple extended support ended for 10.12 in
October 2019.
Maniphest Tasks: T76783, T76184
Differential Revision: https://developer.blender.org/D8179
The spelling and capitalization of package name passed to find_package()
and find_package_handle_standard_args() needs to match.
Silences CMake warning about mismatch.
Differential Revision: https://developer.blender.org/D8247
The upstream version of nasm does not put version information to the
generated object files, which makes linker to show the following
warning:
building for macOS, but linking in object file
Using own patched version of nasm which puts required information to
the object file, making linker happy.
The plan is to either streamline the patch and provide it to the
upstream, or, it that takes too long, get an independent fix from the
upstream.
We don't need it and it was optionally enabled, causing Blender to fail
to link on certain configuration (when Brotli is installed via Homebrew
for example).
The configuration was confused about gettext installed via Homebrew
and isysroot passed to Python's compilation but not to test programs.
After this change `import gettext` still works, but it is unclear how
to test it further,
Differential Revision: https://developer.blender.org/D8231
Set of fixes which had to be made in order to have dependencies built
on own laptop:
- Require bison as a dependent software. It is required by ISPC.
On macOS it is required to be installed via Homebrew. This is because
Bison from Xcode toolchain is too old.
- Made sure Boost is compiled using clang.
Without this gcc was used, and some unsupported command line argument
was passed to it.
- Modify OGG in a way which does in fact pull fixed sized types.
They are defined in stdint.h.
Without this fix FFmpeg will not detect presence of OGG because the
test program fails to compile.
- Force disable zstd compression and make wepb optional for the TIFF
library. Without this TIFF might pick up development libraries from
Homebrew.
Differential Revision: https://developer.blender.org/D8221
Clang Tidy is a Clang based "linter" tool which goal is to help
fixing typical programming errors.
It is run as a separate compile step of every file, which slows
compilation down but allows to fully analyze the file the same
way as compiler does and catch non-trivial bugprone cases.
This change includes:
- CMake option called `WITH_CLANG_TIDY` which enables Clang Tidy
linter tool on all source in the `source/` directory.
This option is only available on Linux, as it is currently the
easiest platform to get the Clang Tidy toolchain to work.
- CMake module which is aimed to find latest available Clang Tidy.
- Set of rules which allows to have Blender fully compiled without
extra issues.
The goal of this change is to provide a base ground so that solving
all the warnings can happen later on, as a team effort.
It should be possible to use Clang Tidy side-by-side with both GCC
and Clang, but there seems to be some tweaks to be done in CMake to
make it really work for Blender. For now use Clang toolchain if
there are issues with GCC+Clang Tidy.
It will be worked on in the nearest future to bring seamless
experience for all configurations.
Currently there is no official way of getting Clang Tidy on macOS,
and on Windows there are some difficulties of hooking up Clang Tidy
from LLVM package to the MSVC compiler toolchain.
The actual warnings in the code will be addressed as a part of the
Code Quality Days, task T78535.
Differential Revision: https://developer.blender.org/D7937
Solves problem with different order of codesign server startup and
mount of network shares: avoids exception happening when server is
started prior to the mounts are ready.
When there is no system python OSL will fail to build the documentation.
Given we don't ship the documentation, this is safe to disable.
Originally part of D8123
When doing a release build the TBB debug libs are not
set which was causing an error during the configure
phase of USD, so always set them even if not used.
This requires ISPC for building OpenImageDenoise, so that is now added as
a dependency as well. Blender itself does not need ISPC for building so it
is not included as part of the precompiled libraries.
Differential Revision: https://developer.blender.org/D7641
The Blender USD code didn't have to change for this upgrade. Pixar's USD
did include a change that we had in the patch, so that's been removed
from our patch now. Some of the USD code that we patched changed as
well.
Is achieved by replacing hard-coded signed/unsigned file names with
"<uuid>" which acts as a "request ID". This way multiple workers can
put their requests into a single directory without collisions. The
code sign server will handle the requests sequentially in an unknown
order.
The directory layout on worker goes as following:
<Worker>
<Builder Name>
blender.git/
build/
install/
lib/
Adding an extra <Builder Name> after build is redundant.
Differential Revision: https://developer.blender.org/D8045
The old URL did have a Git commit hash in it, but apparently the server
was ignoring it and only used the `master` that was also mentioned in the
URL. As a result, every new download would get the latest version from
the `master` branch, invalidating the SHA256 checksum.
I replaced `master` with the actual commit hash. This should make the
situation stable.
No functional changes.
embree marks a few of its functions with a dll_export macro
forcibly exporting these symbols from whatever binary links
them. Given we link embree statically and we do not want these
exports in the blender binary, the macro needs to be a no-op.
This updates python to the latest patch level available for 3.7
also updates some of the packages we rely on:
idna 2.9
urllib3 1.25.9
cerifi 2020.4.5.2
requests 2.23.0
numpy 1.17.5
This upgrade required a few changes:
- Some parts of our patch are no longer necessary, as the USD library
now includes those changes.
- The rest of the patch needed adjustment as the `pxr/base/lib/*`
directories in USD's source code have moved to `pxr/base/*`.
- Updated library names on Windows -- thanks @LazyDodo.
Note that this does not enable the USD Python API for inclusion in
Blender. It just aims at being an as-simple-as-possible version upgrade
of the USD library.
now that we stick to some outdated py version, some distro (like current
debian testing) will feature several python3 dev package, but other
dependant libs like numpy are only built against current default version
of python (3.8 now in deb testing)...
In order to be able to use distro packages we need to allow using higher
versions of python, and set relevant CMake option accordingly.
This is the cluster of OIIO and friends , since they are all kinda tangled best to deal with this as a single unit
OIIO 2.1.15.0
png 1.6.37
jpeg 2.0.4
opencolorio 1.1.1
tiff 4.1.0
OSL 1.10.10
pugixml 1.10
openjpeg 2.3.1
Differential Revision: https://developer.blender.org/D7727
Reviewed by: brecht
The file subversion is no longer used in the Python API or user interface,
and is now internal to Blender.
User interface, Python API and file I/O metadata now use more consistent
formatting for version numbers. Official releases use "2.83.0", "2.83.1",
and releases under development use "2.90.0 Alpha", "2.90.0 Beta".
Some Python add-ons may need to lower the Blender version in bl_info to
(2, 83, 0) or (2, 90, 0) if they used a subversion number higher than 0.
https://wiki.blender.org/wiki/Reference/Release_Notes/2.83/Python_API#Compatibility
This change is in preparation of LTS releases, and also brings us more
in line with semantic versioning.
Fixes T76058.
Differential Revision: https://developer.blender.org/D7748
Campbell Barton
Ankit
Ray Molenkamp
Stefan Werner
Sybren A. Stüvel
Sergey Sharybin
Howard Trickey
Sebastian Parborg
bastien
Sybren A. Stüvel
Philipp Oeser
Brecht Van Lommel
Ankit Meel
Patrick Mours
Sergey Sharybin
Stefan Werner
Tuomo Keskitalo
Brecht Van Lommel