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
This diff updates:
FFmpeg : 4.3.2
libogg : 1.3.4
flac : 1.3.3
vpx : 1.8.2
xvid : 1.3.7
x264 : 33f9e1474613f59392be5ab6a7e7abf60fa63622
x264 seemingly has given up on even providing snapshots
and has been updated to the latest hash available at
this time.
faad has been removed since ffmpeg has not supported
it since 2010.
For a more detailed description of the issue see the commit
message for rB497cd3d7dd6e497be484eb78a8ddb23f53b20343
This change moves fftw to a shared library and reverts the bandaid
we did for 2.83.
Unsure what it is that upsets it so much, but when linking
both sndfile and fftw dynamically, the linker gets confused
and thinks that fftw is importing sf_close from the blender
binary (which makes *NO* sense) leading to a start-up error.
Generating the import library from the .def file using the
ms lib tool creates an import library that works fine.
This is not as much a fix as a work around, but given the real
involves replacing how we build fftw, it is not eligible for 2.83
which is in BCON3 already.
The root of the issue lies with (how we build) fftw3
The first issue is: fftw does not build with MSVC, there are other
dependencies that are not compatible with MSVC and for those we
build the libraries required with mingw64, same for fftw
The second issue is: for reasons unknown we really really really
liked all deps to link statically so wherever possible we did so.
Now during the building of the fftw it linked a few symbols from
libgcc (which we do not ship) like __chkstk_ms, for which we passed
some flags to stop generating calls to it. Problem solved! There
is no way this could possibly turn around and bite us in the rear.
fast forward to today mystery crashes that look like a race condition.
What is happening is, we tell the linker that each thread will require
a 2-megabyte stack, now if every thread immediately allocated 2 megs,
that be 'rough' on the memory usage. So, what happens is (for all apps
not just blender), 2 megs are reserved but not backed by any real memory
and the first page is allocated for use by the stack, now as the stack
grows, it will eventually grow out of that first page, and end up in
an area that has not been allocated yet, to deal with that the allocated
page is followed by a guard page, someone touches the guard page it's
time to grow the stack!
Meanwhile in FFTW is it's doing substantial allocation using alloca
(up to 64 kb) on the stack, jumping over the guard page, and ending
up in reserved but not yet committed memory, causing an access violation.
Now if you think, that doesn't sound right! something should have
protected us from that! You are correct! That thing was __chkstk_ms
which we disabled.
Given we do not want a dependency on libgcc while building with MSVC
the proper solution is to build fftw as a shared library which will
statically link any bits and pieces it needs, however that change
is a little bit too big to be doing in BCON3.
So as a work around, we change the size the stack grows from 8k to
68k which gives fftw a little bit more wiggle room to keep it out
of trouble most of the time.
Note this only sidesteps the issue, this may come up again if the
conditions are just right, and a proper solution will need to be
implemented for 2.90.
Search for all potential library names in each directory, otherwise e.g.
libImath-2_2.a from a system directory will be preferred over libImath.a even
if we specified a directory.
It was disabled in D7520 to keep the pdb's from growing out
of control however the increased link time is just not worth
it.
I'll keep an eye on the dailies and see if we have to come up
with a different solution.
The msvc linker had been warning about libcmt being dragged
in for a bit, finally tracked the issue down to the deps of
jpeg and pthreads which both ignored our cflags.
this diff changes them both to use the dynamic crt rather
than the static one so they'll be in line with all our
other libraries.
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! ;)
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
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.
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
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
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.
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
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.
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
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.
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.
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
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
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
[1] https://docs.microsoft.com/en-us/cpp/build/reference/permissive-standards-conformance
Differential Revision: https://developer.blender.org/D6824
Reviewed By: brecht
This commit adds the download, extract, patch, build, and install of the
Universal Scene Description (USD) library to the `install_deps.sh`
script.
Reviewed By: mont29, LazyDodo
Differential Revision: https://developer.blender.org/D6478
Previously the MSVC environment was setup every time using vcvarsall.bat
when you ran you ran rebuild.cmd, Generally not an issue but after many
rebuilds on the same console, it grows the path environment variable
beyond what is supported and building breaks.
This patch adds a check to see if the environment is setup already
and skips the call to vcvarsall.bat
Also cleans up the double build in the msbuild's version of rebuild.cmd
install.vcxproj will build all that is needed, so no need to do a regular
build first.
oidn puts dllexport on all its functions causing the
blender binary to export these symbols.
this patch fixes this unwanted behaviour.
Differential Revision: https://developer.blender.org/D6647
Reviewers: brecht , sergey
libxml puts dllexport on all its functions causing the
blender binary to export these symbols.
this patch fixes this unwanted behaviour.
Differential Revision: https://developer.blender.org/D6646
Reviewers: brecht , sergey
Freeetype 2.9.1 tags dllexport on most of its functions so these
are now exported from the blender binary. (Same issue as D6563
which fixed it for USD)
Issue has already been fixed upstream so a simple version bump
fixes it.
This patch bumps freetype to 2.10.1
Differential Revision: https://developer.blender.org/D6645
Reviewers: brecht , sergey
OSL 1.10.9 fixes osl-bug 866 [1] which is long standing issue
on windows where paths get un-escaped and osl breaks when you
install it to for instance c:\blender-tests\new-boolean
This patch bumps osl to 1.10.9, and since osl is llvm's
only consumer, llvm/clang were bumped 9.0.1
Removed some of the patches that were no longer needed
Builds and passes all tests on windows and linux
[1] https://github.com/imageworks/OpenShadingLanguage/issues/866
Differential Revision: https://developer.blender.org/D6744
Reviewers: brecht
Adding USD to a lite build fails to build due to boost errors, when you turn
boost on and rebuild still boost errors, boost was silently turned off since
it was not deemed needed. Once boost was forced on, it still fails due to TBB
being off.
This patch fixes:
- The Silent disabling of boost
- Add a check that USD is is not on before doing that
- move the TBB checks to a central location rather than the individual platform files
- Add USD to the TBB checks.
Differential Revision: https://developer.blender.org/D6479
Reviewers: brecht, sybren
Not sure when this happened but apparently the lower bar is now windows 7 [1]
This patch bumps to API version to 0x0601 (Win7) and cleans up any uses that
worked around the globally set API version.
[1] https://www.blender.org/download/requirements/
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D6758
Reduce the number of possible locations used to find libraries,
to simplify troubleshooting.
Only keep '*_ROOT_DIR' and the path used by 'install_deps.sh'.
An educated guess to put ensure order of static libraries initialization.
A bit weird, since OpenImageDenoise should be depending on TBB, but that
is likely being ensured by bf_compositor.
Linking succeeded on my Intel machine, and blenloader_test was passing
when doing manual test on buildbot.
From looking into builder's logs it seems that stamp file is picked
up prior to actual archive: sometimes worker reports missing archive
file, from a code path which is only possible if there is a stamp file.
Could be something with IO scheduling where bigger file is sent to
Samba server after smaller file.
Hopefully with this change this will not happen anymore.
It changes name to be blender-<version>-linux64.
Since CentOS is used as a base host for builds there is no real need
in specifying libc version. Is unlikely anything older could be used
anyway.
Also make bitness to be the same as windows. It is something what
users will read easier.
When building with precompiled libraries on Linux, CMake used boost libs
from the system outside the lib dir. This restricts CMake to use only the
libraries from the precompiled libraries.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D6659
Boost could have picked up system-wide libbz2-dev installed and enable
this compression in iostreams. Nothing really wrong with this, but it
makes it so final Blender binary depends on bz2, which breaks default
linker flags.
This commit makes it so Boost is not using libraries which we don't
need, simplifying linking setup.
Differential Revision: https://developer.blender.org/D6668
This is a more correct fix to the issue Brecht was fixing in D6600.
While the fix in that patch worked fine for linking it broke ASAN
runtime under some circumstances.
For example, `make full debug developer` would compile, but trying
to start blender will cause assert failure in ASAN (related on check
that ASAN is not running already).
Top-level idea: leave it to CMake to keep track of dependency graph.
The root of the issue comes to the fact that target like "blender" is
configured to use a lot of static libraries coming from Blender sources
and to use external static libraries. There is nothing which ensures
order between blender's and external libraries. Only order of blender
libraries is guaranteed.
It was possible that due to a cycle or other circumstances some of
blender libraries would have been passed to linker after libraries
it uses, causing linker errors.
For example, this order will likely fail:
libbf_blenfont.a libfreetype6.a libbf_blenfont.a
This change makes it so blender libraries are explicitly provided
their dependencies to an external libraries, which allows CMake to
ensure they are always linked against them.
General rule here: if bf_foo depends on an external library it is
to be provided to LIBS for bf_foo.
For example, if bf_blenkernel depends on opensubdiv then LIBS in
blenkernel's CMakeLists.txt is to include OPENSUBDIB_LIBRARIES.
The change is made based on searching for used include folders
such as OPENSUBDIV_INCLUDE_DIRS and adding corresponding libraries
to LIBS ion that CMakeLists.txt. Transitive dependencies are not
simplified by this approach, but I am not aware of any downside of
this: CMake should be smart enough to simplify them on its side.
And even if not, this shouldn't affect linking time.
Benefit of not relying on transitive dependencies is that build
system is more robust towards future changes. For example, if
bf_intern_opensubiv is no longer depends on OPENSUBDIV_LIBRARIES
and all such code is moved to bf_blenkernel this will not break
linking.
The not-so-trivial part is change to blender_add_lib (and its
version in Cycles). The complexity is caused by libraries being
provided as a single list argument which doesn't allow to use
different release and debug libraries on Windows. The idea is:
- Have every library prefixed as "optimized" or "debug" if
separation is needed (non-prefixed libraries will be considered
"generic").
- Loop through libraries passed to function and do simple parsing
which will look for "optimized" and "debug" words and specify
following library to corresponding category.
This isn't something particularly great. Alternative would be to
use target_link_libraries() directly, which sounds like more code
but which is more explicit and allows to have more flexibility
and control comparing to wrapper approach.
Tested the following configurations on Linux, macOS and Windows:
- make full debug developer
- make full release developer
- make lite debug developer
- make lite release developer
NOTE: Linux libraries needs to be compiled with D6641 applied,
otherwise, depending on configuration, it's possible to run into
duplicated zlib symbols error.
Differential Revision: https://developer.blender.org/D6642
We compile zlib as own dependency, but are not informing BLOSC
to use it. This leads to zlib symbols defined twice when linking
Blender: one set comes from libz.a and another one from libblosc.a.
Tested on Linux Debian testing and CentOS 7.5.
It is possible that this change on its own will lead to linking
errors after libraries are re-compiled, This will be fixed as
a dedicated fix to Blender's build system.
Reviewed By: brecht, mont29, LazyDodo
Differential Revision: https://developer.blender.org/D6641
Over-lines are used in other large files (keymaps for e.g),
using this add-hoc convention for sections make it easier to
configure editors to jump between them (as I have locally).
Even though we build USD as static, it still feels the need to mark its
symbols with declspec(dllexport) which means the blender binary now exports
these symbols.
this patch fixes that unwanted behaviour, however USD libs still need to
rebuild before this becomes visible in the blender binary
Differential Revision: https://developer.blender.org/D6563
Reviewed By: sybren
The USD landing broke building with clang on windows
due to a couple of reasons:
1) Some incompatibilities in their headers [1] only one
of them was important for us and is included in our patchset
now.
2) clangs lld wanted the full path to the libusd_b library
when using the whole archive link option, while msvc can
figure it out from just the library name.
Tested with clang/msvc and msbuild and ninja generators
[1] https://github.com/PixarAnimationStudios/USD/issues/1030
This aligns with the VFX reference platform 2020 along with the decision
to stick to Python 3.7, see T68774.
Blosc was downgraded to 1.5 as recommended by the OpenVDB documentation.
IlmBase and OpenEXR are now built together with CMake rather separately
using autoconf.
Differential Revision: https://developer.blender.org/D6593
Even though we build USD as static, it still feels the need to mark its
symbols with declspec(dllexport) which means the blender binary now exports
these symbols.
this patch fixes that unwanted behaviour, however USD libs still need to
rebuild before this becomes visible in the blender binary
Differential Revision: https://developer.blender.org/D6563
Reviewed By: sybren
The USD landing broke building with clang on windows
due to a couple of reasons:
1) Some incompatibilities in their headers [1] only one
of them was important for us and is included in our patchset
now.
2) clangs lld wanted the full path to the libusd_b library
when using the whole archive link option, while msvc can
figure it out from just the library name.
Tested with clang/msvc and msbuild and ninja generators
[1] https://github.com/PixarAnimationStudios/USD/issues/1030
For no apparent reason, when building Alembic the script would always
re-download and re-extract the Alembic source code. This is no longer the
case, and it now only happens if the source directory is missing. Since the
source directory name contains the Alembic version, it will automatically
trigger a download+extract when the version changes.
Previously, when an unknown parameter was passed to `install_deps.sh`,
the script would just show "Wrong parameter!" without any context. This
can make it hard to figure out what's exactly going wrong. Now it prints
which parameter it thinks is wrong.
Smaller changes in the build files to reflect the new Mantaflow macro.
Reviewed By: sergey
Maniphest Tasks: T59995
Differential Revision: https://developer.blender.org/D3853
Brecht Van Lommel
Ray Molenkamp
Sybren A. Stüvel
Sergey Sharybin
Bastien Montagne
Campbell Barton
Brecht Van Lommel
Stefan Werner
Christian Rauch
Anthony Edlin
Nathan Craddock
Bastien Montagne
Mateusz Grzeliński
Julian Eisel
blender
Bastien Montagne
Julian Eisel
Phillip Thomas
Brecht Van Lommel
Stefan Werner
Philipp Oeser
Simon G
Sebastián Barschkis