This change removes 32 bit support from the helper make.bat scripts
as we are dropping official 32 bit support, you can still build for
32 bit by configuring your build yourself using cmake and pointing
the LIBDIR cmake variable to your own 32 bit library folder.
This has faster builds, error checks and tests. The number of cmake options
for this type of thing has grown over the years and it's convenient to be
able to point new developers to a single target.
Previously the combination of all these options did not work correctly, now
all tests should pass.
The easiest way to use this is with the make wrapper, for example:
make full developer debug
Or set it manually with CMake:
cmake -C ../blender/build_files/cmake/config/blender_developer.cmake .
Differential Revision: https://developer.blender.org/D5149
make.bat now supports optional parameters to restrict
the formatting to a specific folder. Multiple paths
may be given
example:
make.bat format source/blender/blenkernel source/blender/gpu
SVN takes a long time to sync even if there are no updates,
the `code_update` parameter gives the option opt out of the
SVN updates.
This is a developer option, people just wanting to build
blender and not do any development are highly recommended
to keep using the `update` method.
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.
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
For llvm 6 the visual studio integration was 'not great' and we had
our own, which broke when llvm 7.0.1 came out. llvm now has properly
supported integration available on the VS market place hence we can
retire our custom support.
The recent change also used the buildtools instead of the regular compiler, you now have to explicitly state what you want to use :
2017 - the standard msvc compiler
2017pre - the msvc compiler from the preview installation
2017b - the msvc compiler from the buildtools installation
This will currently only work for the RelWithDebInfo configuration since asan
does not support the debug crt. for source line information in the reports,
you need a copy of llvm-symbolizer in the blender folder or set the
ASAN_SYMBOLIZER_PATH environment variable to point to it. Currently (as of
6.0.0) llvm-symbolizer does not ship with the binary clang/llvm distribution.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D3446
This commit contains the minimum to make clang build/work with blender, asan and ninja build support is forthcoming
Things to note:
1) Builds and runs, and is able to pass all tests (except for the freestyle_stroke_material.blend test which was broken at that time for all platforms by the looks of it)
2) It's slightly faster than msvc when using cycles. (time in seconds, on an i7-3370)
victor_cpu
msvc:3099.51
clang:2796.43
pavillon_barcelona_cpu
msvc:1872.05
clang:1827.72
koro_cpu
msvc:1097.58
clang:1006.51
fishy_cat_cpu
msvc:815.37
clang:722.2
classroom_cpu
msvc:1705.39
clang:1575.43
bmw27_cpu
msvc:552.38
clang:561.53
barbershop_interior_cpu
msvc:2134.93
clang:1922.33
3) clang on windows uses a drop in replacement for the Microsoft cl.exe (takes some of the Microsoft parameters, but not all, and takes some of the clang parameters but not all) and uses ms headers + libraries + linker, so you still need visual studio installed and will use our existing vc14 svn libs.
4) X64 only currently, X86 builds but crashes on startup.
5) Tested with llvm/clang 6.0.0
6) Requires visual studio integration, available at https://github.com/LazyDodo/llvm-vs2017-integration
7) The Microsoft compiler spawns a few copies of cl in parallel to get faster build times, clang doesn't, so the build time is 3-4x slower than with msvc.
8) No openmp support yet. Have not looked at this much, the binary distribution of clang doesn't seem to include it on windows.
9) No ASAN support yet, some of the sanitizers can be made to work, but it was decided to leave support out of this commit.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D3304
ninja is an alternative to msbuild designed for fast rebuilds. However there is no IDE support, builds only from the command line.
Comparison between msbuild and ninja for a full build, build time in seconds.
Full Clean Build
msbuild 867.5
Ninja 801.2
Difference -66.3 (-7.6%)
Minor Change
msbuild 43.0
Ninja 14.9
Difference -28.1 (-64.4%)
No Changes
msbuild 23.0
Ninja 6.1
Difference -16.9 (-73.5%)
make.bat was starting to become hard to maintain, this refactors it into separate batch files for each stage of the process.
-Improved detection of msvc2013/2015
-Improved failure handling.
-Added check for working msbuild and C++ compiler
-Added verbose switch to ease trouble shooting.
-Added Check if svn/cmake/git are in the path before using them
-Display the build configuration before asking to download the libraries
-Offer an option to recover an interrupted checkout of the libraries.
-Automatically check out sub-modules in-case they are missing.
