For the official GitHub mirror and other repositories that do not include LFS
files, this adds an `lfs-fallback` remote. It will be used automatically if a
file can't be found on the regular remote.
Ref #137215
Co-authored-by: Sergey Sharybin <sergey@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/137615
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
Support importing scripts without running their logic to
allow basic validation (see #130746).
Parts of !131037 were used.
Co-authored-by: Bastien Montagne <bastien@blender.org>
Remove assert statement from make_update.py, making it ready for any
architecture.
Add riscv 32, 64 and 128 bit cpu architecture with little/big endian
to Blender's BLI_build_config.h and Libmv's build_config.h
Tested (to compile) on riscv64 little endian machine.
Pull Request: https://projects.blender.org/blender/blender/pulls/130920
This is not an officially supported platform, but it was working before
so might as well keep it up to date.
* Tweak logic for various BLENDER_PLATFORM_ARM checks
* Use linux_arm64 name for folders, matching Windows and macOS
* CUDA is enabled, SYCL and HIP are not
* Tested to work on Rocky Linux 8
This change adds `--prune-destructive` command line argument to the
`make_update.py` script which ensures directories which used to be
an in-worktree checkout do not exist. Currently it is addons and
addons_contrib folders.
This gives buildbot an ability to ensure checkout used for build is
correct, regardless of which branch or patch was built there.
The option is needed because sometimes it is still required to be
able to build patches against v330 or v360 which still use the old
style of addons.
Alternative solution could be to ignore the folders in the INSTALL
command, but this could have impact on users who wants to package
custom addons.
The downside of this solution is that buildbot potentially will be
downloading addons and addons_contrib repositories every time it
builds a patch against v330 or v360. It should not be a problem in
practice since the repositories are rather small, and patches for
these tracks are not built very often.
Ref #126557
Pull Request: https://projects.blender.org/blender/blender/pulls/127798
The extensions system allows to extend Blender with connectivity to the internet. Right now it means Blender can
discover and install add-ons and themes directly from the internet, and notify users about their updates.
By default this is disabled (opt-in), and users can enable it the first time they try to install an extension or visit
the Prefences > Extensions tab. If this is enabled, Blender will automatically check for updates for
extensions.blender.org upon startup.
When will Blender access the remote repositories:
* Every time you open the Preferences → Extensions: ALL the enabled repositories get checked for the latest info (json)
* Every time you try to install by dragging: ALL the enabled repositories get checked for the latest info (json).
* Every time you start Blender: selected repositories get checked for the latest info (json).
------------------
From the Blender code point of view, this means that most of the add-ons and themes originally bundled with Blender
will now be available from the online platform, instead of bundled with Blender. The exception are add-ons which are
deemed core functionality which just happened to be written as Python add-ons.
Links:
* Original Extenesions Platform Announcement: https://code.blender.org/2022/10/blender-extensions-platform/
* Extensions website: https://extensions.blender.org/
* User Manual: https://docs.blender.org/manual/en/4.2/extensions/index.html#extensions-index
* Technical specifications: https://developer.blender.org/docs/features/extensions/
* Changes on add-ons bundling: https://devtalk.blender.org/t/changes-to-add-on-bundling-4-2-onwards/34593
------------------
This PR does the following:
* Move extensions out of experimental.
* No longer install `scripts/addons` & `scripts/addons_contrib`.
* Add `scripts/addons_core` to blender's repository.
These add-ons will still be bundled with Blender and will be always enabled in the future, with their preferences
moved to be more closely integrated with the rest of Blender. This will happen during the remaining bcon2 period.
For more details, see #121830
From scripts/addons:
* copy_global_transform.py
* hydra_storm
* io_anim_bvh
* io_curve_svg
* io_mesh_uv_layout
* io_scene_fbx
* io_scene_gltf2
* pose_library
* ui_translate
* viewport_vr_preview
Extra: bl_pkg (scripts/addons_contrib)
Note: The STL (legacy) add-on is going to be moved to the extensions platform. There is already a C++ version on core
which is enabled by default.
All the other add-ons are already available at extensions.blender.org. To use them you need to:
* Go to User Preferences > Extensions
* You will be greated with an "Online Extensions" message, click on "Enable Repository".
* Search the add-on you are looking for (e.g, Import Images as Planes).
* Click on Install
Over time their maintaince will be transferred over to the community so their development can carry on. If you used to
help maintain a bundled add-on please read: https://devtalk.blender.org/t/changes-to-add-on-bundling-4-2-onwards/34593
Ref: !121825
The `make update` will now always update all initialized submodules,
including the library ones.
The `make_update.py --no-libraries` will neither initialize nor update
pre-compiled libraries or tests.
Pull Request: https://projects.blender.org/blender/blender/pulls/118812
Solves the issue of the script potentially sitting for a long time
without having any progress reported. Confusingly, such behavior
depends on Git version.
In older versions (< 2.33) there will be progress reported, but it
then got changed by the commit in Git:
7a132c628e
The delayed checkout is exactly how Git LFS integrates into the Git
process. Another affecting factor for the behavior is that submodule
configured to use "checkout" update policy is forced to have quite
flag passed to the "git checkout":
https://github.com/git/git/blob/v2.43.2/builtin/submodule--helper.c#L2258
This is done to avoid the long message at the end of checkout about
the detached state of HEAD, with instructions how to resolve that.
There are two possible solutions: either use "rebase" update policy
for submodules, or skip Git LFS download during the submodule update.
Changing the update policy is possible, but it needs to be done with
a bit of care, and possible revised process for updating/merging
tests data.
This change follows the second idea of delaying LFS download for a
later step, so the process is the following:
- Run `git submodule update`, but tell Git LFS to not resolve the links
by using GIT_LFS_SKIP_SMUDGE=1 environment variable.
- Run `git lfs pull` for the submodule, to resolve the links.
Doing so bypasses hardcoded silencing in the Git. It also potentially
allows to recover from an aborted download process.
The `git lfs pull` seems to be a nominal step to resolve the LFS links
after the smudging has been skipped. It is also how in earlier Git
versions some Windows limitations were bypassed:
https://www.mankier.com/7/git-lfs-faq
The submodule update now also receives the "--progress" flag, which
logs the initial Git repository checkout process, which further
improves the feedback.
The byproduct of this change is that an error during precompiled
libraries and tests data update is not considered to be fatal.
It seems to be more fitting with other update steps, and allows
more easily reuse some code.
There is also a cosmetic change: the messages at the end of the
update process now have their own header, allowing more easily
see them in the wall-of-text.
Pull Request: https://projects.blender.org/blender/blender/pulls/118673
Likewise, skip tests update when --use-tests is not provided.
It was a bit of ambiguous situation because libraries and tests
are technically submodules. After some feedback it seems that it
is better to ignore submodule for libraries and tests unless
requested explicitly.
Pull Request: https://projects.blender.org/blender/blender/pulls/118631
If LFS hooks are installed manually the automatic installation would
fail.
This change makes it so `lfs` is a valid command of `git`, ensuring
that the package is installed. If the installation fails assume it
is due to tricky local setup, and do not fail.
Pull Request: https://projects.blender.org/blender/blender/pulls/118618
- git lfs install was called a bit too late, after the libraries
has been checked out, leaving the checkout in a non-resolved
state.
- Update blender code first, allowing proper submodule hash to
be pulled.
Pull Request: https://projects.blender.org/blender/blender/pulls/118615
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
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
Fix the issue when upstream workflow is used and the addons fork does
not yet have the release branch. In this case create a local branch
which is based on the upstream/<branch> but does not track anything.
Typically with such workflow the local branches will track origin, but
since the origin does not have the branch yet it is not possible to
track it.
Test plan:
- Use upstream workflow
- Have a fork of addons, which does not have blender-v3.6-release
- Run make update
The error message:
```
Updating scripts/addons ...
git fetch origin
git fetch upstream
git checkout -t origin/blender-v3.6-release
fatal: 'origin/blender-v3.6-release' is not a commit and a branch 'blender-v3.6-release' cannot be created from it
make: *** [update] Error 128
```
Pull Request: https://projects.blender.org/blender/blender/pulls/108197
- make_update.external_script_add_origin_if_needed
returned None or an empty string. As neither where checked simply
return None.
- git_get_remote_url had an incorrect annotation.
Apparently `git checkout -t` is only allowed to happen for new branches.
Added a code which checks whether the branch already exists and it so
uses the `git checkout <branch>`.
Pull Request #105234
If repository has multiple remotes with the same name of branch
checking out to the branch using simple `git checkout branch` exists
with an error: this is because there is ambiguity w.r.t which remote
to track.
Now the code explicitly provides remote to track, preferring to use
"origin" first (which is to be used for Blender style of workflow,
and Github style workflow when there is a fork available), and use
"upstream" if there is no origin.
Pull Request #105176
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
This reverts commit 19222627c6.
Something went wrong here, seems like this commit merged the main branch
into the release branch, which should never be done.
Apparently, the 65bit Intel architecture is presented differently
on Linux and Windows.
Allow both variants for the command line, so that semantically the
command line argument can be seen as a lower case platform.machine.
