There is no CMake version yet that support VS2026, support is
currently limited to ninja based builds.
CMake does not know where to look for the MSVC 2026 Runtime
it copies the wrong CRT leading to startup issues, for this reason
WITH_WINDOWS_BUNDLE_CRT has been disabled for VS2026 + CMake < 4.2.0.
Builds done with VS2026 are for this reason *NOT* distributable to
end users at this point in time.
CMake 4.2.0 Is *expected* to have VS 2026 support [1]
But further testing is likely required.
Things of note:
- They stopped using the "preview" channel and have rebranded to
"Insiders" the make.bat options have been updated accordingly to
select the 2026 Insiders build, you need to pass 2026i to make.bat
- All tests seem to pass on my system
- No new warnings, pretty smooth update
[1] https://gitlab.kitware.com/cmake/cmake/-/merge_requests/11168
Add missing trailing backslash to BLENDER_DIR path in git submodule
update command to match the formatting used elsewhere in the script.
This prevents the following error when python is not found during
the update:
cannot change to .. submodule update lib/windows_x64': Invalid argument
Pull Request: https://projects.blender.org/blender/blender/pulls/139616
This change moves the tests data files and publish folder of assets
repository to the main blender.git repository as LFS files.
The goal of this change is to eliminate toil of modifying tests,
cherry-picking changes to LFS branches, adding tests as part of a
PR which brings new features or fixes.
More detailed explanation and conversation can be found in the
design task.
Ref #137215
Pull Request: https://projects.blender.org/blender/blender/pulls/137219
This was introduced during EEVEE-next developement
cycle to not make the buildbot fail because of EEVEE
render tests.
These have stabilized now and we can remove this option.
Pull Request: https://projects.blender.org/blender/blender/pulls/137545
This switches clang to be the default compiler on Windows ARM64, allowing for an override to MSVC.
Turns out MSVC builds have been broken for months, but nobody checked, so I'm just switching them off for now and setting clang as the default.
These updated scripts allow for the msbuild generator to use an external (ie, non-MSVC) clang installation properly, otherwise they failed.
They also allow for users to specify their own desired clang compiler via an environment variable.
An update to the docs will come seperately.
Pull Request: https://projects.blender.org/blender/blender/pulls/134566
- WITH_WINDOWS_EXTERNAL_MANIFEST is now required even for ninja
builds, this previously was not the case. so just apply it
across all build flavours on windows.
- fmsc-version=1922 is no longer needed, was required back when
support for clang on windows landed, is fine without it now.
- /MP gives better build performance when building from the IDE
makes no difference for a ninja build which wasn't struggling in
that department anyhow.
2019 no longer has a preview track, so support for it can
safely be removed. The help also incorrectly advertised
asan as a clang only feature, which is no longer true as
msvc supports it these days.
Both the draw manager and gpu backend used the same compilation
directive for enablement. This PR seperates them into
`WITH_GPU_DRAW_TESTS` for draw manager related tests and
`WITH_GPU_BACKEND_TESTS` for gpu backend related tests.
Pull Request: https://projects.blender.org/blender/blender/pulls/132018
The build commands for `ninja clean` on Windows were wrong - one had
the cmake executable duplicated and one was not using the correct
environment variable and also had missing quotes for paths that
contained spaces. Tested working on with `make ninja clean` and
`make ninja clean release`.
Pull Request: https://projects.blender.org/blender/blender/pulls/128802
This generates a `license.md` file with all the relevant information about
the different libraries and their respecive licenses.
This should replace: THIRD-PARTY-LICENSES.txt
Important files:
* `make_license.py` (main script called by `make license`.
* `licenses.json` (file to add the definition of new licenses).
* `licenses/*/*.txt` (individual license files.
The `license.md` groups the libraries per license, list their
corresponding copyright information and include the complete license.
Code includes contributions from:
* Campbell Barton (multi-line parser for versions.cmake).
* Thomas Dinges (Windows support for `make license`).
Part of: !129018
This gets Windows ARM64 to compile with clang-cl, which gives up to 40% performance improvements in certain scenes rendered with cycles, compared to MSVC.
This is all tested using LLVM 18.1.8 and a VS2022 `vcvarsall` window.
Subsequent PRs with various lib version updates, etc to go in at a later point.
Pull Request: https://projects.blender.org/blender/blender/pulls/124182
autopep8_format_paths.py was never wired up in the windows tooling,
this PR wires it up, to get around a 8191 limitation for command
lines on windows an alternative "--no-subprocess" option has been
introduced to call the pep8 module directly from python.
TODO: A subprocess is still used for getting the version information
Contributors:
- @campbellbarton fixes to autopep8_format_paths.py to support
the -no-subprocess option.
Pull Request: https://projects.blender.org/blender/blender/pulls/120794
Support for building blender with clang on windows on x64 was added
years ago but given there are no active users support has crumbled a
bit.
This PR brings the build system back into working order but upstream
patches in openVDB are still required for a successful build see PR
#120317 for details.
Blender when build with clang the classroom scenes rendered on the cpu
with cycles is seeing a 5% reduction in render time on both an
AMD 7700x and an Intel 14900k.
* Only works on machines with a Qualcomm Snapdragon 8cx Gen3 or above.
Older generation devices are not and will not be supported due to
some driver issues
* Requires VS2022 for building.
* Uses new MSVC preprocessor for sse2neon compatibility.
* SIMD is not enabled, waiting on conversion of blenlib to C++.
Ref #119126
Pull Request: https://projects.blender.org/blender/blender/pulls/117036
First time builders get spooked by this warning and start
installing python trying to resolve it. This isn't needed
and we should only warn about python being missing if the
lib folder is cloned, but python is still somehow not found.
This was "fixed" a few times before, but it took a bit
to find the right filename to check for the new library
folder.
git on windows is giving no status updates while git lfs
is downloading the libs, causing people to assume its
stuck and interrupt the download. This change adds a
rather large visual message telling people not to do
that.
also it was not respecting people selecting n on the lib
download so some extra messaging has been added there
as well.
Git escaped a quote and used all of the cli arguments as the
folder name.
Also fixes:
- Progress on the initial clone so it doesn't appear stuck
- re-detect python after updating libs, so you don't have to run
make update twice on a fresh clone.
- Hide python not found warning unless the lib folder exists (this
seemingly got lost in one of the merges)
This change makes it so build system and update utilities for Blender builds
are using pre-compiled libraries and other resources attached as Git modules
instead of using checkout of SVN repositories in the parent folder.
The directory layout:
```
* release/datafiles/
* assets/ -> blender-assets.git
* publish/
* ...
* README.txt
* lib/
* darwin_x64/ -> lib-darwin_x64.git
* darwin_arm64/ -> lib-darwin_arm64.git
* linux_x64/ -> lib-linux_x64.git
* windows_x64/ -> lib-windows_x64.git
* tests/
* data/ -> blender-test-data.git
```
The changes about configuring the actual Git sub-modules are not included
into this patch, as those require repository to actually exist before it
can be used.
The assets submodule is enabled by default, and the rest of them are
disabled. This means that if someone runs `git submodule update --init`
they will not get heavy libraries. The platform-specific and tests
related submodules are enabled when using `make update` or `make test`.
All the submodules are tracked: this means that when new commits are
done to the submodule, the blender.git repository is to be updated to
point them to the new hash. This causes some extra manual work, but it
allows to more easily update Blender and its dependencies to known good
state when performing operations like bisect.
Ref #108978
Pull Request: https://projects.blender.org/blender/blender/pulls/117946
People running `make update` first time, will not have a lib
folder yet, and get a warning about python being missing, this
sends some of them off onto somewhat of a wild goose chase
installing python when this is really not needed since it's
included in our libraries.
This change, changes the warning to only emit when the lib
folder exists, but python is missing in the lib folder and
there actually is likely an issue with the lib folder.
Add silently fail option to GPU based render tests. This is a pre-requisite to enable
render tests on the buildbot. By default these render tests will pass silently.
* Test will pass when using the `--pass-silently` arguments.
* Only crashes will be reported as failed tests.
* To find out failing test, review the test reports.
`WITH_GPU_RENDER_TESTS_SILENT` compile option can be used to let tests pass (default)
or fail (default for developers).
Although some tests fail, they still passed. In the generated render report,
the silently passed failures are correctly reported to be failures.
Pull Request: https://projects.blender.org/blender/blender/pulls/117629
The build scripts are still referring to gpu tests as being opengl.
Although they can also use Metal or Vulkan. This PR only replaces
the work `opengl` with `gpu` for build options.
Special note is that the windows argument `with_opengl_tests` is
also replaced with `with_gpu_tests` for consistency.
Pull Request: https://projects.blender.org/blender/blender/pulls/116030
This broke when we moved the submodules around and no one ever noticed
This will now list:
-The current branch
-The current branch hash
-Addons branch
-Addons branch hash
-Libs url
-Libs revision
-Libs last-changed-date
So it'll be a little easier to diagnose what exactly the state of
things are when someone asks for help building.
the path for clang_format_paths.py changed when the submodules
moved but format.cmd was never updated for that.
the work previously done by check_submodules.cmd is now done by
make_update.py so this file can be removed.
This commit implements described in the #104573.
The goal is to fix the confusion of the submodule hashes change, which are not
ideal for any of the supported git-module configuration (they are either always
visible causing confusion, or silently staged and committed, also causing
confusion).
This commit replaces submodules with a checkout of addons and addons_contrib,
covered by the .gitignore, and locale and developer tools are moved to the
main repository.
This also changes the paths:
- /release/scripts are moved to the /scripts
- /source/tools are moved to the /tools
- /release/datafiles/locale is moved to /locale
This is done to avoid conflicts when using bisect, and also allow buildbot to
automatically "recover" wgen building older or newer branches/patches.
Running `make update` will initialize the local checkout to the changed
repository configuration.
Another aspect of the change is that the make update will support Github style
of remote organization (origin remote pointing to thy fork, upstream remote
pointing to the upstream blender/blender.git).
Pull Request #104755
The issue we ran into a lot is we have a python script that updates
git+SVN. Which works fine most of the time, except when we have a
python update in SVN, or worse a python version change. Python really
doesn't enjoy having its files being deleted or changed while it is
running and users generally end up with a corrupted lib folder.
This change updates the library folder using svn.exe first before
letting the python script run sidestepping the issue in most cases.
The python script will still run and do the more elaborate work
like updating git and switching SVN branches which could still
run into issues cause python still doesn't like being changed
while running but there's not a whole lot we can about that,
for *most* people however things will just work now.
Several sub commands tried on their own
to locate python, given I wanted to look
in several locations for a broader libdir
compatibility this is best done in a
central location.
Python 3.9 is still preferred, but if
3.10-3.12 are available that be accepted
as well.
note: this is about the python version
make.bat uses to run various python helper
scripts, this change has no influence on
the python version blender itself uses.
SVN seems to die randomly *a lot* during
large updates for some users, and I'm no
closer to finding out why that keeps happening.
"The internet" seems to imply some AV vendors
may be at fault here but nothing conclusive.
The solution however is repeatedly running
`svn cleanup`and `svn update` in the library
folder to repair the corruption and finish the
update.
This change adds a small convenience helper
to automate the repair.
This is done inside the make.bat code rather
than the shared python based update code, since
python lives in the library folder and may
or may not exist when this corruption occurs.
This adds support to compile the html python api docs from the command line by running `make doc_py` matching support between windows and unix.
This patch also makes it so the compiler is not needed if you set the `blender_bin` variable, this affects icon generation as well.
In the future, I want to move away from generating the build output in the build directory but that can come in a later change.
Reviewed By: LazyDodo
Differential Revision: https://developer.blender.org/D12144
This adds support for building the icons from make.bat
unlike bash there is no passing environment variables
on the command line.
The scripts go out of their way to locate both blender
and inkscape however if they are not found, the user is
given a helpful error message telling them how to set
the variables.
Although some extra help can be given there, if your
normal build is a 2019 full build running
`make 2019 full icons`
will help it find the blender executable as well.
finally if you know the name of your build folder
running
`make builddir build_windows_Lite_x64_vc16_Release icons`
will also work, if all fails you can point directly to
the blender executable by running
`set BLENDER_BIN=c:\where\blender\lives\blender.exe`
before running `make icons` or `make icons_geom`
The python scripts needed some small modifications since
without the PATHEXT, SystemRoot and SystemDrive
environment variables python will not initialize properly
on windows. (Not blender related, even mainline python
won't start without those)
