After aa02002491333c42060373bc84f1ff5d2c76b4ce we started passing the
user name to the create_release function and this was being interpreted
as the git tag.
Like linux releases, export a tar.xz files containing most llvm tools,
including non toolchain utilities, llvm-config, llvm-link and others.
We do this by reconfiguring cmake one last time at the last step,
running the install target so we do not need to recompile anything.
Fix#51192Fix#53052
The default GitHub token does not have read permissions on the org, so
we need to use a custom token in order to read the members of the
llvm-release-managers team.
As described in [test-release.sh ninja install does builds in Phase
3](https://github.com/llvm/llvm-project/issues/80999), considerable
parts of Phase 3 of a `test-release.sh` build are run by `ninja
install`, ignoring both `$Verbose` and the parallelism set via `-j NUM`.
This patches fixes this by not specifying any explicit build target for
Phase 3, thus running the full build as usual.
Tested on `sparc64-unknown-linux-gnu`.
The current test-release.sh script does not install the necessary
compiler-rt builtin's during Phase 1 on AIX, resulting on a
non-functional Phase 1 clang. Futhermore, the installation is also
necessary for Phase 2 on AIX.
Co-authored-by: Alison Zhang <alisonzhang@ibm.com>
* Split out the lit release job and the documentation build job into
their own workflow files. This makes it possible to manually run these
jobs via workflow_dispatch.
* Improve tag/user validation and ensure it gets run for each release
task.
Add two new flags to the release script:
`--skip-checkout` builds from the local source folder, instead of the downloaded source package
`--local-python` uses whichever local Python version is installed, instead of a specific version (3.10)
If the LLVM source is already in `C:\git\llvm-project` then one can do in a admin prompt:
```
C:\git>llvm-project\llvm\utils\release\build_llvm_release.bat --version 18.0.0 --x64 --skip-checkout
...
```
This allows for iterating more easily on build issues, just before a new LLVM package is made.
Also fix some warnings on the second stage build (`-Wbackend-plugin`).
You can now pass the -use-cmake-cache option to test-release.sh and it
will use a predefined cache file for building the release. This will
make it easier to reproduce the builds and add other enhancements like
PGO or bolt optimizations.
---------
Co-authored-by: Konrad Kleine <konrad.kleine@posteo.de>
Compiler-rt built-ins are needed to have a functional Phase 1 clang
compiler on AIX. This PR adds compiler-rt to the runtime_list during Phase 1 to avoid
this problem.
---------
Co-authored-by: Alison Zhang <alisonzhang@ibm.com>
Doxygen documentation takes very long to build, when making releases we
want to get the normal documentation up earlier so that we don't have to
wait for doxygen documentation.
This PR just adds the flag to disable doxygen builds, I will then later
make a PR that changes the actions to first build the normal docs and
another job to build the doxygen docs.
While doing a test-release.sh run on FreeBSD, I ran into a sed error due
to the introduction of the GNU extension '\s' in commit 500587e23dfd.
Scanning for blanks (spaces and tabs) could be done in a more portable
fashion using the [[:blank:]] character class. But it is easier to avoid
the original problem, which is that the projects and runtime lists have
to be separated by semicolons, and cannot start with a semicolon.
Instead, use the shell's alternate value parameter expansion mechanism,
which makes it easy to append items to lists with separators in between,
and without any leading separator. This also avoids having to run sed on
the end result.
In addition, build any selected runtimes in the second phase, otherwise
the third phase can fail to find several symbols in compiler-rt, if that
has been built. This is because the host's compiler-rt is not guaranteed
to have those symbols.
Reviewed By: tstellar
Differential Revision: https://reviews.llvm.org/D145884
`test-release.sh` is too silent in some cases:
- Only the build proper is run verbosely, but `check-all` is not.
- `lit` is run without `-v`, so in case of failures one cannot see what's
actually wrong.
This patch fixes both issues, running all `${MAKE}` invocations with
`$Verbose` (except for `${MAKE} install` where it would only add noise),
and running `lit` with `-v`.
Tested on `x86_64-pc-linux-gnu` and `arm64-apple-darwin21.6`.
Differential Revision: https://reviews.llvm.org/D143249
The stage1 and stage2 builds aren't packaged, so we only need to build
enough of the toolchain to build the next phase.
Reviewed By: thieta, amyk
Differential Revision: https://reviews.llvm.org/D141552
MLIR supports standalone builds, so I think it makes sense to also
produce a release tarball for the MLIR subproject.
Differential Revision: https://reviews.llvm.org/D141919
* Generate `//:vars.bzl` from `llvm/CMakeLists.txt`
`_extract_cmake_settings()` generates `//:vars.bzl` in `llvm_configure()`.
It would be easier to use external commands like sed(1) and python.
For portability, I think the parser should run on Starlark.
`@llvm-project//:vars.bzl` may be loaded from both WORKSPACE and BUILD.
At the moment, `vars.bzl` provides some values as string.
- CMAKE_CXX_STANDARD = "17"
- LLVM_VERSION_MAJOR = "16"
- LLVM_VERSION_MINOR = "0"
- LLVM_VERSION_PATCH = "0"
- LLVM_VERSION = "16.0.0"
- llvm_vars = (dict of these values)
`CMAKE_CXX_STANDARD` may be used to configure toolchain.
* Use `//vars.bzl` for each BUILD files
It would be smarter if the BUILD phase could generate `llvm-config.h`.
Since I am afraid of the discussion in D126581, I just remove
LLVM_VERSION stuff out of the static `llvm-config.h`.
* Eliminate Bazel stuff in 'bump-version.py'
Current version of `bump-version.py` tries to substitute CLANG_VERSION.
It is the reason why I modify bump-version in this change rather than
incoming patch.
Differential Revision: https://reviews.llvm.org/D136392
Unlike projects, runtimes doesn't have a default set of names.
This means you get a leading space at the start, which gets converted
to a ';' giving ";<runtime name>;<runtime name>".
CMake then errors because the "" before the first ';' is treated
as a runtime name and of course it's not a valid name.
Fix this by removing the leading spaces from runtimes before we
insert the ';'.
Reviewed By: ldionne
Differential Revision: https://reviews.llvm.org/D139306
420d7ccbac0f499a6ff9595bdbfa99cd3376df22 introduced BACKEND_PACKAGE_STRING to
replace `PACKAGE_VERSION` (llvm/Config/config.h) to support standalone builds.
This is used in the output of `clang -cc1 -v`.
Since llvm-config.h is available for both standalone and non-standalone builds,
we can just use `LLVM_VERSION_STRING` from llvm-config.h.
clang/cmake/modules/AddClang.cmake uses `VERSION_STRING "${CLANG_VERSION} (${BACKEND_PACKAGE_STRING})"`.
Just simplify it to `"${CLANG_VERSION}"` so that we can remove the CMake
variable BACKEND_PACKAGE_STRING.
Reviewed By: tstellar
Differential Revision: https://reviews.llvm.org/D136660
Instead of hardcoding several VS paths, use vswhere.exe (available from
VS 2017) to get latest version available.
Reviewed By: hans, thieta
Differential Revision: https://reviews.llvm.org/D135873
Options:
--version: [required] version to build
--help: display this help
--x86: build and test x86 variant
--x64: build and test x64 variant
Note: At least one variant to build is required.
Example: build_llvm_release.bat --version 15.0.0 --x64
Reviewed By: hans, thieta
Differential Revision: https://reviews.llvm.org/D135255
Instead of hardcoding a specific VS install, try sequentially:
- %VSINSTALLDIR% (already set from a vs prompt)
- 2019/Enterprise
- 2019/Professional
- 2019/Community
- 2019/BuildTools
It stops when one is found and set vsdevcmd env var.
Differential revision: https://reviews.llvm.org/D135173
There are many files that needs to be updated when you
bump the version of LLVM. This script tries to automate
that in order to make the release managers job easier.
Reviewed By: kwk, hans, ldionne
Differential Revision: https://reviews.llvm.org/D133923
If libcxxabi is not included CMake will error out:
Cannot find target libcxxabi-SHARED
I ran into this doing the 15.0.0 release
Differential Revision: https://reviews.llvm.org/D133475
As discussed here:
https://discourse.llvm.org/t/build-llvm-release-bat-script-options
Add a function to parse command line arguments: `parse_args`.
The format for the arguments is:
Boolean: --option
Value: --option<separator>value
with `<separator>` being: space, colon, semicolon or equal sign
Command line usage example:
my-batch-file.bat --build --type=release --version 123
It will create 3 variables:
`build` with the value `true`
`type` with the value `release`
`version` with the value `123`
Usage:
set "build="
set "type="
set "version="
REM Parse arguments.
call :parse_args %*
if defined build (
...
)
if %type%=='release' (
...
)
if %version%=='123' (
...
)
Add a flag to enable BOLT. Should be used in x86-64 and
AArch64 linux builds only, since BOLT doesn't really support other
targets and is mostly tested on these two systems as hosts.
Reviewed By: tstellar
Differential Revision: https://reviews.llvm.org/D131703
For each release tag, this action will create a new release on GitHub,
and for each -final tag, this action will build the documentation and
upload it to GitHub.
Reviewed By: hans, kwk
Differential Revision: https://reviews.llvm.org/D99780
