| Age | Commit message (Collapse) | Author |
|---|
|
regression from rB116d7b0042bba7d6cabd8e04c7d020ac3816caf3
|
|
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.
|
|
Given we are officially on 3.10 now, look
for that version first, followed by any future
version before falling back to 3.9
|
|
Contributed by luzpaz.
Differential Revision: https://developer.blender.org/D14203
|
|
The lower bar for building blender
is now MSVC 2019 16.9.16.
|
|
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.
|
|
It was still looking for the 3.7 folder
rather than 3.9
|
|
|
|
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)
|
|
VS2019 is the preferred version to use these
days, look for it before looking for 2017
and 2022.
|
|
This adds preliminary VS 2022 support, since
there currently is no CMake version that
supports the VS2022 IDE only ninja support
was tested.
IDE support should work without any additional
changes as soon as an updated CMake becomes
available.
As VS2022 appears to keep binary compatibility
with earlier MSVC versions, the current SVN
libraries will work for this version.
|
|
This enables ASAN support when used with VS 16.9
enable as usual in cmake with the WITH_COMPILER_ASAN
option, or when using make.bat just tag on `asan'
to the invocation, ie: `make lite 2019 asan`
MSVC: Asan support for 16.9
This enables ASAN support when used with VS 16.9
enable as usual in cmake with the WITH_COMPILER_ASAN
option, or when using make.bat just tag on `asan'
to the invocation, ie: `make lite 2019 asan`
Differential Revision: https://developer.blender.org/D7794
Reviewed By: brecht, sergey
|
|
The windows build leaves a convenience helper script
in the build folder called, rebuild.cmd. This change
passes any parameters you give rebuild.cmd to ninja
so you can easily pass it additional parameters without
having to edit the batch file manually.
|
|
sccache [1] is one of the few ccache like solutions that will
work on windows.
sccache support can be enabled with the `WITH_WINDOWS_SCCACHE`
cmake option however it will only will work with ninja as the
build system, msbuild is not supported currently.
Advanced option, developes are expected to obtain and configure
sccache on their own.
```
Full build no cache 1428.90s (100.00%)
Full build cached 434.34s ( 30.40%)
```
[1] https://github.com/mozilla/sccache
Reviewed By: nicholas_rishel, Brecht
Differential Revision: https://developer.blender.org/D7466
|
|
Inspired by @mrwhite in D7295
|
|
VS2015 has not been supported for a while now but make.bat
still had some support for it.
|
|
|
|
|
|
Previously the MSVC environment was setup every time using vcvarsall.bat
when you ran you ran rebuild.cmd, Generally not an issue but after many
rebuilds on the same console, it grows the path environment variable
beyond what is supported and building breaks.
This patch adds a check to see if the environment is setup already
and skips the call to vcvarsall.bat
Also cleans up the double build in the msbuild's version of rebuild.cmd
install.vcxproj will build all that is needed, so no need to do a regular
build first.
|
|
This change switches windows to the dynamic C runtime
avoiding issues coming from mixing the static and dynamic
runtime like the ones outlined in [1]
[1] https://developer.blender.org/D5387#122165
Differential Revision: https://developer.blender.org/D6175
Reviewed by: @Sergey
|
|
|
|
1) Clang was given the wrong VS version to emulate when used in
combination with VS2019 causing build issues.
2) The erroneous supplied parameter `-std::c++11`caused CMake to
fail running its compiler detection scripts.
|
|
When calling make.bat multiple times to rebuild blender
make.bat failed to rebuild if a custom build dir was set.
reported and fixed on chat by @dgsantana
|
|
Differential Revision: https://developer.blender.org/D5715
|
|
|
|
|
|
We are no longer depended on a system python being installed.
|
|
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
|
|
When you call make.bat without a target the build folder name would
have a double underscore in it which looked odd.
|
|
|
|
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
|
|
The noge option has been removed but was still
shown in the help text.
|
|
Optional parameter nobuildinfo turns WITH_BUILDINFO Off
which is helpful when doing development.
|
|
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.
|
|
|
|
following the change on linux.
|
|
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.
|
|
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.
|
|
Shouldn't cause issues, but better safe than sorry.
|
|
|
|
|
|
|
