For some reason the buildinfo header was not re-generated. The root
reason is not really clear to me, so simply remove the header similar
to the CMake cache.
There are couple of caviats currently:
- The script requires system-wide Python 3 available in the current
search PATH as python.exe.
This will get addressed soon by distributing unpacked Python binary
in our libraries.
- Since the libraries folder is to be known, this requires to have
MSVC detected. Not too bad, since formatting is still way slower
than detection, but still doesn't feel ideal.
Use CMake's target_link_libraries instead of manually maintaining
library dependencies in a single list.
In practice adding new libraries often ended up being guess-work,
now each library lists the libraries it uses.
This was used for the game player executable so libraries
could optionally link to stubs.
If we need this functionality it can be done using target-properties
as described in T46725.
No functional change, this adds LIB definition and args to cmake files.
Without this it's difficult to migrate away from 'BLENDER_SORTED_LIBS'
since there are many platforms/configurations that could break when
changing linking order.
Manually add and enable WITHOUT_SORTED_LIBS to try building
without sorted libs (currently fails since all variables are empty).
This check will eventually be removed.
See T46725.
Draco is added as a library under extern/ and builds a shared library that is
installed into the Python site-packages. This is then loaded by the glTF add-on
to do mesh compression.
Differential Revision: https://developer.blender.org/D4501
Most of the source tarballs are retrieved via http, but a few remain
that are still downloaded via ftp. This causes some pain with corporate
firewalls, so moving the last two URIs to http helps ease the build process.
Reviewers: sergey
Differential Revision: https://developer.blender.org/D4192
For custom path selected during 'install_deps.sh' using '--source'/'--install', paths for blosc, embree and opencollada are not printed/inclued into BUILD_NOTES.txt file.
As '/opt/lib/<package>' paths are hardcoded into CMakes's Find* modules, this error is not noticeable, but for custom paths it is.
This patch includes those fixes/prints for those packages.
Reviewers: mont29
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D4574
Even though that one is not really useful just to build Blender, we can
as well explicitely include it here, since all 'default' Blender builds
will include full clang/llvm stack anyway (for Cycles and deps)...
This version fixes various bugs, and there is no need anymore to use both
9.1 and 10.0 for different cards.
There is a bug related to WITH_CYCLES_CUBIN_COMPILER and bump mapping in the
regression tests, so that remains disabled same as it was for CUDA 10.0.
Fix T59286: CUDA bake failing on some cards.
Fix T56858: CUDA 9.2 and 10 issues.
llvm generates some header files at build time that differ between
debug/release causing linker errors when you used the release headers
for a debug build.
llvm generates some header files at build time that differ between
debug/release causing linker errors when you used the release headers
for a debug build.
Bug introduced on: 1f22e3f311e74031c3c01714117d759d3e3de3f1.
This was making regular Mac builds to fail, where they were not failing before.
Tested by William Reynish.
This enables static linking of libstdc++ by default when building using
`WITH_STATIC_LIBS`. This makes builds more portable for anyone making
static builds (in particular for older systems).
Reviewed By: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4393
Bug introduced on: 1f22e3f311e74031c3c01714117d759d3e3de3f1.
This was making regular Mac builds to fail, where they were not failing before.
Tested by William Reynish.
Two changes:
Removed the explicit version for the macOS SDK, recent
versions of Xcode have a symlink to the newest SDK.
Fixed the build script for OpenMP by removing extra ' marks that
install_name_tool took literally and replaced INSTALL_PATH with
INSTALL_DIR.
VS2019 is binary compatible with the existing vc14 libraries and no
new libraries libs are required in svn.
VS2019 support requires cmake 3.14.
VS2019 is still in pre-release state, you are required to explicitly
select the pre-release version by using:
make full 2019pre
VS2019 is binary compatible with the existing vc14 libraries and no
new libraries libs are required in svn.
VS2019 support requires cmake 3.14.
VS2019 is still in pre-release state, you are required to explicitly
select the pre-release version by using:
make full 2019pre
