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
The zip files were too large to be practical, so they were never
shipped. Reverting to reduce build time and complexity of the script.
This reverts commit 4486aa03c5f431ba33a1d1ac9991da912e3decd9.
Check in updates based on how the latest release was built [0] and add
the bug fix from [1] which allows LLDB to start.
Other changes which had accumulated in the local release script:
- Don't build the clang format plugin (VS has the functionality built
in now)
- Disable tests that have been failing (I'll try to follow up and
re-enable them)
- Switch to Python 3.10
- Jump through more hoops to make LLDB pick the right Python.
0. https://discourse.llvm.org/t/14-0-4-final-has-been-tagged/62750/3
1. https://github.com/llvm/llvm-project/issues/54589
This flag silents the build output of test-release.sh so that
it can be used in CI systems a bit better. It will still log
the build output to the log files but not echo it to stdout.
Reviewed By: tstellar
Differential Revision: https://reviews.llvm.org/D122146
The solution using append was reported not to work, but additionally it
would use the contents of the checked-out source tree instead of the git
tag or commit. This uses `git archive`, so it will use the right commit,
and at least for me (with GNU tar) it seems to work as intended.
Should fix#53281.
Reviewed By: kwk
Differential Revision: https://reviews.llvm.org/D121972
Instead of using the deprecated LLVM_ENABLE_PROJECTS build, use the
default runtimes build. This is just as fast, but it's supported.
Differential Revision: https://reviews.llvm.org/D119275
This patch adds an option (no-clang-tools) to disable building clang-tools-extra when
performing release testing. Prior to this patch, clang-tools-extra was built by default,
but on some platforms (such as AIX), clang-tools-extra is not supported, and so we do
not normally build it. Furthermore, this change should not change the invocation for
targets that build clang-tools-extra normally.
Differential Revision: https://reviews.llvm.org/D119520
I've split the git archive generation into three steps:
1. generate pure tarball
2. append top-level cmake directory to all tarballs
3. compress the archive
This was inspired by D118252 and can be considered an alternative
approach for all projects to have access to the shared cmake
directory when building in standalone mode.
When generating source tarballs on my local laptop it takes 9 minutes and 45 seconds WITH this patch applied. When this patch is not applied, it takes 9minutes and 38 seconds. That means, this patch introduces a slowdown of 7 seconds, which seems fair.
Reviewed By: tstellar
Differential Revision: https://reviews.llvm.org/D118481
I think this was just being ignored before, but now it crashes because
we're checking if the projects that we're trying to enable are valid.
There is no test-suite project (it's a separate repo with separate
handling), so we should never try to enable it.
Differential Revision: https://reviews.llvm.org/D119322
The tools used by test-suite are originally configured to compile with cc by
default, and this is dictated by TEST_SUITE_HOST_CC.
However, it is possible that on some systems that the version of cc may either
not be present or it may not be able to compile the tools as it may be too old,
which could be an issue seen during release testing.
This patch updates the compiler to be the default build compiler that is used
for release testing. If no such compiler it specified, then cc will be set as
the test-suite tools build compiler by default (as it already is set under
TEST_SUITE_HOST_CC).
Differential Revision: https://reviews.llvm.org/D118357
