Age | Commit message (Collapse) | Author |
|
Many modern computers support a lot of threads (parrallel building
jobs), but are somewhat restricted in memory, when some building jobs
can require several GB each.
Ninja builder has pools, which extend the usual `-j X` make
parallelizing option, by allowing to specify different numbers of
parallel jobs for different targets.
This commit defines three pools, one for linking, one for usual compile,
and one for compiling some 'heavy' cpp libs, when a single file can
require GB of RAM in full debug builds.
Simply enabling WITH_NINJA_POOL_JOBS will try to set default sensible
values for those three pools based on your machine specifications, you
can then tweak further the values of NINJA_MAX_NUM_PARALLEL_ settings,
if you like.
On my system (8 cores, 16GB RAM), it allows to build a full debug with
all ASAN options build with roughly 7GB of RAM used at most, pretty much
as quickly as without that option (which would require up to 11GB of
available RAM at some points).
Review task: D4780.
|
|
following the change on linux.
|
|
Differential Revision: https://developer.blender.org/D4704
|
|
|
|
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.
|
|
Recent cmake work made the debug build link both python37.dll and python37_d.dll
|
|
|
|
Already used by install_deps.sh
|
|
Don't construct the full build environment, following
feedback from Ray.
|
|
Makes more sense to place in 'utils_maintenance'.
|
|
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.
|
|
|
|
Needed for building without sorted libs.
|
|
Linking empty libs gave an error.
|
|
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
|
|
FFMPEG removed ffserver and that option alltogether three years ago.
|
|
|
|
Were not needed previously, but the functions branch needs them.
|
|
|
|
|
|
|
|
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.
|
|
|
|
Otherwise we can silently build an OpenAL that can't actually playback audio.
|
|
We can keep these in sync for now.
|
|
Otherwise we can silently build an OpenAL that can't actually playback audio.
|
|
|
|
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.
|
|
Patch by Campbell.
|
|
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
|
|
|