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
Note that this is turned off by default and must be enabled at build time with the CMake WITH_CYCLES_EMBREE flag.
Embree must be built as a static library with ray masking turned on, the `make deps` scripts have been updated accordingly.
There, Embree is off by default too and must be enabled with the WITH_EMBREE flag.
Using Embree allows for much faster rendering of deformation motion blur while reducing the memory footprint.
TODO: GPU implementation, deduplication of data, leveraging more of Embrees features (e.g. tessellation cache).
Differential Revision: https://developer.blender.org/D3682
The script clearly states:
This makes the presumption that you are include al.h like
#include "al.h"
and not
#include <AL/al.h>
The reason for this is that the latter is not entirely portable.
Windows/Creative Labs does not by default put their headers in AL/ and
OS X uses the convention <OpenAL/al.h>.
This commit makes default precompiled OpenAL to be properly detected
and also removes hack on MacOS which was finding the OpenAL package but
then was overwriting include directory.
Note, that new audaspace in 2.8 is using expected #include <al.h>.
This is in preparation of upgrading our library dependencies, some of which
need C++11. We already use C++11 in blender2.8 and for Windows and macOS, so
this just affects Linux.
On many distributions this will not require any changes, on some
install_deps.sh will need to be run again to rebuild libraries.
Differential Revision: https://developer.blender.org/D3568
When run from make.bat the environment is setup correctly and the VCToolsRedistDir environment variable exists, on later invocations of cmake this may no longer be the case and a warning was emitted about the missing runtime. we can't rely on InstallRequiredSystemLibraries.cmake here since it uses the compiler version to figure out the correct location and it doesn't know how to deal with clang.
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%)
This patch changes the huge list of projects in visual studio into a nice tree matching the source folder structure. see D2823 for details.
Differential Revision: http://developer.blender.org/D2823
cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
Deleting the old internal audaspace.
Major changes from there are:
- The whole library was refactored to use C++11.
- Many stability and performance improvements.
- Major Python API refactor:
- Most requested: Play self generated sounds using numpy arrays.
- For games: Sound list, random sounds and dynamic music.
- Writing sounds to files.
- Sequencing API.
- Opening sound devices, eg. Jack.
- Ability to choose different OpenAL devices in the user settings.
The Issue
=======
For a long time now MinGW has been unsupported and unmaintained and at this point,
it looks like something that we should just leave behind and move on.
Why Remove
==========
One of the big motivations for MinGW back in the day is that it was free compared to MSVC which was licensed based.
However, now that this is no longer true we have basically stopped updating the need CMake files.
Along with the CMake files, there are several patches to the extern libs needed to make this work. For example, see:
https://developer.blender.org/diffusion/B/browse/master/extern/carve/patches/mingw_w64.patch
If we wanted to keep MinGW then we would need to make more custom patches to the external libs and
this is not something our platform maintainers are willing to do.
For example, here is the patches needed to build python: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-python3
Fixes T51301
Differential Revision: https://developer.blender.org/D2648
Basically title says it all.
The goal is to make platform maintenance easier, so you don't have
to constantly scroll back and forth looking for if() branches to
check which exact platform you're currently working on.
Ideally we also would move option defaults to a platform files,
but that i'm not sure how to implement in a nice way yet.
Reviewers: mont29
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D2148
