Age | Commit message (Collapse) | Author |
|
Follow upstream convention.
|
|
The file subversion is no longer used in the Python API or user interface,
and is now internal to Blender.
User interface, Python API and file I/O metadata now use more consistent
formatting for version numbers. Official releases use "2.83.0", "2.83.1",
and releases under development use "2.90.0 Alpha", "2.90.0 Beta".
Some Python add-ons may need to lower the Blender version in bl_info to
(2, 83, 0) or (2, 90, 0) if they used a subversion number higher than 0.
https://wiki.blender.org/wiki/Reference/Release_Notes/2.83/Python_API#Compatibility
This change is in preparation of LTS releases, and also brings us more
in line with semantic versioning.
Fixes T76058.
Differential Revision: https://developer.blender.org/D7748
|
|
Works similarly to Windows configuration where buildbot worker and
codesign machines are communicating with each other using network
drive.
|
|
It changes name to be blender-<version>-linux64.
Since CentOS is used as a base host for builds there is no real need
in specifying libc version. Is unlikely anything older could be used
anyway.
Also make bitness to be the same as windows. It is something what
users will read easier.
|
|
xz compresses 25% better than bz2, reducing download times and server load.
The numbers:
blender-2.80-linux-glibc217-x86_64.tar.bz2 (release): 134 886 174 bytes
with xz: 96 181 604 bytes (-28.7%)
with xz -9: 93 871 548 bytes (-30.4%)
blender-2.81-7c1fbe24ca33-linux-glibc217-x86_64.tar.bz2 (beta): 173 600 363 bytes
with xz: 133 100 664 bytes (-23.3%)
with xz -9: 129 534 124 bytes (-25.4%)
xz also decompresses more than twice as fast as bz2, however compression needs
four times as long (on my 7-year-old laptop 3-4 minutes instead of <1).
Also xz has become more common than bz2, e.g. Debian/Ubuntu deb packages have
been xz-compressed for years, so the dpkg package manager as well as systemd
and grub all depend on liblzma being present, whereas bz2 is becoming more and
more optional.
Current Linux archives also include the UID/GID of whatever user account
happens to be used for building by the blender.org infrastructure. If someone
then installs these archives as root e.g. to /usr/local/... and doesn't pay
full attention the files remain owned by a regular user, which is a serious
security issue. This patch fixes that by setting the UID/GID to 0.
Differential Revision: https://developer.blender.org/D6138
|
|
This changes integrates code signing steps into a buildbot worker
process.
The configuration requires having a separate machine running with
a shared folder access between the signing machine and worker machine.
Actual signing is happening as a "POST-INSTALL" script run by CMake,
which allows to sign any binary which ends up in the final bundle.
Additionally, such way allows to avoid signing binaries in the build
folder (if we were signing as a built process, which iwas another
alternative).
Such complexity is needed on platforms which are using CPack to
generate final bundle: CPack runs INSTALL target into its own location,
so it is useless to run signing on a folder which is considered INSTALL
by the buildbot worker.
There is a signing script which can be used as a standalone tool,
making it possible to hook up signing for macOS's bundler.
There is a dummy Linux signer implementation, which can be activated
by returning True from mock_codesign in linux_code_signer.py.
Main purpose of this signer is to give an ability to develop the
scripts on Linux environment, without going to Windows VM.
The code is based on D6036 from Nathan Letwory.
Differential Revision: https://developer.blender.org/D6216
|
|
|
|
Removes custom logic from buildbot's packing step.
This also removes icons/ folder, but CMake was already copying the
icons to the root of the install folder.
|
|
|
|
* Auto detect rc and release version cycle in BKE_blender_version.h.
* On Windows, generate zip and installer if a release is detected.
* On macOS, always generate a dmg instead of zip.
* Use standard package names without hash if a release is detected.
* Buildbot package names now match platform names in releases.
Ref T67056
Differential Revision: https://developer.blender.org/D5643
|
|
* Move common code into buildbot_utils.py
* Remove legacy code from removed builders
* Split code into smaller functions
Differential Revision: https://developer.blender.org/D5642
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- BKE_blender_version.h (only version defines & versionstr).
- BKE_blender_copybuffer.h (currently only used for view3d copy/paste).
- BKE_blender_undo.h (global undo functions).
- BKE_blendfile.h (high level blend file read/write API).
|
|
|
|
- Remove deprecated/unused builders
- Remove unused SCons OSX slave configuration
- Remove SCons slave logic, it is not giving error about unknown building
system used for the slave.
|
|
|
|
|
|
|
|
This is also has been moved to the CMake, no need to keep old dying code around.
|
|
It is now totally covered by cmake slave.
|
|
This is totally matching the way how buildbot was naming the directory.
Currently there's a bit of code duplication, but it'll be eliminated once
we'll get rid of SCons ;)
|
|
|
|
|
|
Path is to be fully specified, so it's independent form the working directory.
|
|
Also de-duplicate bit of code.
|
|
|
|
What a shame..
|
|
|
|
|
|
|
|
This we we don't have difference between builders on different platforms.
|
|
Should be no functional changes.
|
|
It is expected to be in the build folder for the cmake.
Ideally it should be build/<builder> or install/<builder> but that's a bit more
involved change. Will look into it later.
|
|
Was using wrong working directory.
|
|
This is so called "seems to work in dry tests" commit which is aimed to switch
linux release environment to CMake.
Some notes:
- There's no special handle of libstdc++, but it wasn't really static for quite
some time in SCons configuration and nobody really complained.
- It was quite tricky to get OpenMP linked statically with just using some
configuration so we went ahead and added a special option to CMake now which is
only exist on Linux and advertised as shouldn't be used.
- Packing is happening manually in slave_pack.py. This is because we have to add
some really special files to the archive (mesa libraries for example) which we
can't really handle from CMake/CPack in a nice generic way.
Don't think it's bad approach, at least crappynness is localized and it's not
_that_ crappy anyway.
- Windows buildbot should keep working, but needs doublechecing. It's just a
build folder changed, but you never know what it might imply.
- Some further tweaks are likely needed to ensure all builders are working.
Thanks Campbell for assistance in this patch!
|
|
|
|
|
|
Did this in packaging buildbot rule because of several reasons:
- CMake doesn't deliver name of package which we expect it to be for buildbot
- CMake doesn't really know that building happens for buildbot
- Making default CPAck name matching buildbot's naming is kinda stupid
Probably we can pass CPack name via command line arguments, but i'm happy with
the current state and one might change things in the future.
|
|
also remove empty class parenthesis
|
|
in the process
|
|
CPack generating NSIS and WiX installers should also work
|