Change the dylib folder relative to `Blender` executable to be
the same as before rB652fbc200500497a67bd11d18b786587ba34e3d9 and same
as bpy.so : `@loader_path/../Resources/${BLENDER_VERSION}/lib`
* Revert back to OpenMP 9.0.1 due to bug causing cloth physics test to fail.
* Skip flex build on macOS to avoid link error, only reason we build this is
due to old flex version on Linux CentOS 7.
* Fix PNG cmake argument that expects lowercase on instead of ON.
Ref T90507, T88438
This adds support to compile the html python api docs from the command line by running `make doc_py` matching support between windows and unix.
This patch also makes it so the compiler is not needed if you set the `blender_bin` variable, this affects icon generation as well.
In the future, I want to move away from generating the build output in the build directory but that can come in a later change.
Reviewed By: LazyDodo
Differential Revision: https://developer.blender.org/D12144
The Xcode IDE can also benefit from the options:
- WINDOWS_USE_VISUAL_STUDIO_SOURCE_FOLDERS
- WINDOWS_USE_VISUAL_STUDIO_PROJECT_FOLDERS
So add suport to these options and also renames them as they are no
longer limited to just Windows and Visual Studio.
Reviewed By: brecht, ankitm
Differential Revision: https://developer.blender.org/D12132
This adds support for building the icons from make.bat
unlike bash there is no passing environment variables
on the command line.
The scripts go out of their way to locate both blender
and inkscape however if they are not found, the user is
given a helpful error message telling them how to set
the variables.
Although some extra help can be given there, if your
normal build is a 2019 full build running
`make 2019 full icons`
will help it find the blender executable as well.
finally if you know the name of your build folder
running
`make builddir build_windows_Lite_x64_vc16_Release icons`
will also work, if all fails you can point directly to
the blender executable by running
`set BLENDER_BIN=c:\where\blender\lives\blender.exe`
before running `make icons` or `make icons_geom`
The python scripts needed some small modifications since
without the PATHEXT, SystemRoot and SystemDrive
environment variables python will not initialize properly
on windows. (Not blender related, even mainline python
won't start without those)
For some reasons looks like those shortcuts could get out of sync, which
created weird hard to understand building errors.
So for sake of simplicity and security, just re-create them all the
time, just like we update ld paths.
For Blender.app: dropping libomp.dylib next to Blender executable is
enough for it getting picked up since `@executable_path` is an rpath.
For non-distributed binaries datatoc, makesdna, tests etc, code for
copying libomp.dylib to build folder is removed and replaced by
CMake's rpath option for *build* tree.
For bpy.so, the post build rpath change has also been replaced by CMake
rpath option for *install* tree.
Since -id has been changed in D11748, remove the
`install_name_tool -change ...` command.
Any dylib can just be dropped at `MAC_BLENDER_TARGET_DYLIBS_DIR`
hereafter. Appending dylib path to `CMAKE_BUILD_RPATH` will be needed
for datatoc etc if linked against one (instead of copying the
dylibs around).
Reviewed By: #platform_macos, brecht
Differential Revision: https://developer.blender.org/D11997
This is causing issues for some users launching Blender, because EGL indirectly
requires GLVND, which is not installed by default on e.g. Ubuntu.
This reverts commit 0b18a618b8.
Fixes T90374
Ref D12034
This will replace GLX with EGL for X11. GLEW does not support GLX and EGL
at the same time. Most distributions build GLEW with GLX support, so we
have to use the externally provided GLEW and build with EGL support.
This effectively sets WITH_SYSTEM_GLEW to OFF for all Linux configurations.
Differential Revision: https://developer.blender.org/D12034
This caused a blender load error on windows N,
given we do not use these codecs they can safely
be disabled.
This will fix T90200 once the new libraries are
in SVN
This has been a huge pain to get working, for several reasons (new flags
needed, patching is now mandatory, etc.).
Further more, discovered that debian OIIO package is now silently
relying on OpenCV, without even proper handling of this dependency (at
least in the `-dev` package), so had to revert to force-build own OIIO
again on that distro for the time being.
Ref. T88438.
We shipped the whole bin folder for llvm/clang
while we only needed clang-format, by shipping
just the bits we need we save about 700 megabytes
off our svn lib download.
WITH_CYCLES_DEBUG was used for rendering BVH debugging passes. But since we
mainly use Embree an OptiX now, this information is no longer important.
WITH_CYCLES_DEBUG_NAN will enable additional checks for NaNs and invalid values
in the kernel, for Cycles developers. Previously these asserts where enabled in
all debug builds, but this is too likely to crash Blender in scenes that render
fine regardless of the NaNs. So this is behind a CMake option now.
Fixes T90240
Pass `-DLINKSTATIC=ON` to the OSL CMake, to ensure it statically links to
our libpng. Previously this was only applied on Windows, it's now on all
platforms.
Builtbot is switching over from json to yaml. Both
configuration files should be kept in sync for now.
The json file will be removed when everything works as expected.
This diff somewhat snowballed out of updating OIDN to 1.4.1 it had some
changes that allowed us to remove the arm hacks we had in place and
revert to using identical versions for a whole bunch of deps. But that
required an update to ISPC which needed a newer LLVM and if we're
updating LLVM we may as well update OSL, and when we update OSL, OIIO
may as well be dragged in soo......anyhow...
This diff updates:
LLVM 9.0.0 (11.0.1 for mac/arm) -> 12.0.0
OIIO 2.1.15.0 -> 2.2.15.1
OSL 1.11.10.0 -> 1.11.14.1
winflex_bison 2.5.5-> 2.5.24 (ispc needed newer bison, windows only dep)
OIDN 1.4.0 -> 1.4.1
ISPC v1.14.1(random hash for mac/arm) -> v1.16.0
Flex 2.6.4 (ISPC needed newer Flex than available on CentOS 7)
and removes most of the "special arm/mac" versions. I think just ssl and
embree are left with special versions.
notable changes:
@LazyDodo included some clang headers in the linux/mac harvest which are
needed to start writing custom clang based tooling like D9465 these were
already shipping on windows, but not the other platforms.
[macOS] Change the `LC_ID_DYLIB` of OpenMP for {D11997}. This changes
where the executables look for dylibs.
Reviewed By: sebbas, LazyDodo
Differential Revision: https://developer.blender.org/D11748
This fixes a performance regression on Ampere cards, on specific scenes like
classroom. For cycles-x there is little difference, but this is still helpful
for LTS releases, and we need to upgrade at some point anyway.
Simple upgrade of OpenXR to 1.0.17. A version bump was enough, no
Blender code had to change.
Reviewed By: LazyDodo, mont29
Differential Revision: https://developer.blender.org/D11848
The wayland support requires the following development packages:
libwayland-dev, wayland-protocols, libegl-dev, libxkbcommon-dev,
libdbus-1-dev, linux-libc-dev
ld: warning: could not create compact unwind for _ff_rl_init_vlc: stack
subq instruction is too different from dwarf stack size
Similar to rB2de5de57c58521862e0fecc95fc474ea347b7468
Differential Revision: https://developer.blender.org/D11796
Blender did not support to input East Asian characters (Chinese, Japanese,
Korean) on macOS. This patch adds support for Japanese input, by implementing
the appropriate processing for the NSTextInputClient protocol.
Technical notes:
* The conversion candidate window is drawn by the input method program calling
`firstRectForCharacterRange`.
* The string before confirmation (called `composite` in blender) is handled in
the `setMarkedText` method called by the input method program.
* The string after confirmation (called `result` in the blender) is processed
in the `insertText` method called by the input method program.
Ref T51283
Differential Revision: https://developer.blender.org/D11695
In certain CMake configurations it was possible
that OCIO gave linker errors due to it thinking
it was using the shared library rather than the
static library we ship.
This patch fixes many minor spelling mistakes, all in comments or
console output. Mostly contractions like can't, won't, don't, its/it's,
etc.
Differential Revision: https://developer.blender.org/D11663
Reviewed by Harley Acheson
This adds preliminary VS 2022 support, since
there currently is no CMake version that
supports the VS2022 IDE only ninja support
was tested.
IDE support should work without any additional
changes as soon as an updated CMake becomes
available.
As VS2022 appears to keep binary compatibility
with earlier MSVC versions, the current SVN
libraries will work for this version.
CMake builder and install deps changes, precompiled libraries are still to be
committed.
Ref T88438, T88434
Differential Revision: https://developer.blender.org/D11486
