420d7ccbac 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 4486aa03c5.
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
Instead of using the (now deprecated) Projects build for libcxx, libcxxabi,
libunwind and compiler-rt, this patch uses the Bootstrapping build. This
implies that Clang will be built from scratch, and then the runtimes will
be built using that just-built Clang instead of the system compiler.
This is the correct way of assembling a toolchain, since we don't want
to ship runtimes that were built with a non-Clang compiler (or a
potentially older Clang).
Differential Revision: https://reviews.llvm.org/D112748
This patch adds allows the LIT runs within test-release.sh to obey the width that
is passed into the script. This is accomplished by adding the width in the LLVM_LIT_ARGS
CMake configuration.
Differential Revision: https://reviews.llvm.org/D115350
There's a lot of history behind this, so here's a summary:
1. I stopped forcing -fPIC when building the runtimes in 30f305efe2,
before the LLVM 9 release back in 2019.
2. Someone complained that libc++.a couldn't be used in shared libraries
built without -fPIC (http://llvm.org/PR43604) since the LLVM 9 release.
This had been caused by my removal of -fPIC when building libc++.a in (1).
3. I suggested two ways of fixing the issue, the first being to force
-fPIC back unconditionally (http://llvm.org/D104328), and the second
being to specify that option explicitly when building the LLVM release
(http://llvm.org/D104327). We converged on the first solution.
4. I landed D104328, which forced building the runtimes with -fPIC.
This was included in the LLVM 13.0 release.
5. People complained about that and requested that we be able to
customize this setting (basically we should have done the second
solution).
This patch makes it such that the LLVM release script will specifically
ask for building with -fPIC using CMAKE_POSITION_INDEPENDENT_CODE,
however by default the runtimes will not force that option onto users.
This patch has the unintended effect that Clang and the LLVM libraries
(not only the runtime ones like libc++) will also be built with -fPIC
in the release. It would be better if we could specify that -fPIC is to
be used only when building the runtimes, however this is left as a
future improvement. The release should probably be using a bootstrapping
build and passing those options to the stage that builds the runtimes
only, see https://reviews.llvm.org/D112748 for that change.
Differential Revision: https://reviews.llvm.org/D110261
Upon testing the use of test-release.sh on AIX, the script initially fails
because chrpath is not present on AIX. This patch adds checks for AIX and allows
the script to continue running to completion.
Differential Revision: https://reviews.llvm.org/D115046
This change adds the ability to create source tarballs for unreleased or untagged code by providing the `--git-ref <GIT_REF>` flag to the `llvm/utils/release/export.sh` script. This is useful for creating daily snapshot tarballs that can easily be consumed by packagers who want to build a daily snapshot.
The default behavior of `export.sh` hasn't changed.
You may also provide a `--template` argument to say how the artifacts
are supposed to be named (as suggested by @hans).
The `-help` output of `export.sh` was changed quite significantly to look like this:
```
Export the Git sources and build tarballs from them.
Usage: export.sh [-release|--release <major>.<minor>.<patch>]
[-rc|--rc <num>]
[-final|--final]
[-git-ref|--git-ref <git-ref>]
[-template|--template <template>]
Flags:
-release | --release <major>.<minor>.<patch> The version number of the release
-rc | --rc <num> The release candidate number
-final | --final When provided, this option will disable the rc flag
-git-ref | --git-ref <git-ref> (optional) Use <git-ref> to determine the release and don't export the test-suite files
-template | --template <template> (optional) Possible placeholders: $PROJECT $YYYYMMDD $GIT_REF $RELEASE $RC.
Defaults to '${PROJECT}-${RELEASE}${RC}.src.tar.xz'.
The following list shows the filenames (with <placeholders>) for the artifacts
that are being generated (given that you don't touch --template).
* llvm-<RELEASE><RC>.src.tar.xz
* clang-<RELEASE><RC>.src.tar.xz
* compiler-rt-<RELEASE><RC>.src.tar.xz
* libcxx-<RELEASE><RC>.src.tar.xz
* libcxxabi-<RELEASE><RC>.src.tar.xz
* libclc-<RELEASE><RC>.src.tar.xz
* clang-tools-extra-<RELEASE><RC>.src.tar.xz
* polly-<RELEASE><RC>.src.tar.xz
* lldb-<RELEASE><RC>.src.tar.xz
* lld-<RELEASE><RC>.src.tar.xz
* openmp-<RELEASE><RC>.src.tar.xz
* libunwind-<RELEASE><RC>.src.tar.xz
* flang-<RELEASE><RC>.src.tar.xz
Additional files being generated:
* llvm-project-<RELEASE><RC>.src.tar.xz (the complete LLVM source project)
* test-suite-<RELEASE><RC>.src.tar.xz (only when not using --git-ref)
To ease the creation of snapshot builds, we also provide these files
* llvm-release-<YYYYMMDD>.txt (contains the <RELEASE> as a text)
* llvm-rc-<YYYYMMDD>.txt (contains the rc version passed to the invocation of export.sh)
* llvm-git-revision-<YYYYMMDD>.txt (contains the current git revision sha1)
Example values for the placeholders:
* <RELEASE> -> 13.0.0
* <YYYYMMDD> -> 20210414
* <RC> -> rc4 (will be empty when using --git-ref)
In order to generate snapshots of the upstream main branch you could do this for example:
export.sh --git-ref upstream/main --template '${PROJECT}-${YYYYMMDD}.src.tar.xz'
```
Reviewed By: tstellar
Differential Revision: https://reviews.llvm.org/D101446
Don't prefer python2's virtualenv when setting up the test-suite.
Always use python3 instead, since that's what we support everywhere else
anyway.
Differential Revision: https://reviews.llvm.org/D106941
LLDB is currently not selected in LLVM release testing and thus it
doesnt make its way into prebuilt binaries which build with default
configuration. This patch enables LLDB by default in test-release
script.
Assuming LLDB build by default was disabled back in 2016 LLDB support
for various architectures has a long way since then. It has buildbots
for most architectures and supports a case to be included by default.
Also lldb build can easily be disabled in case some release managers
choose to do so.
Reviewed By: tstellar
Differential Revision: https://reviews.llvm.org/D101864
Currently the tarballs contain superfluous metadata, like the user name
of the packager and via Pax headers even the PID of the tar process that
packaged the files. We build the monorepo projects directly from the git
repo using "git archive" and for the test-suite we add some flags as
recommended by https://reproducible-builds.org/docs/archives/. We don't
use numeric owners though to be compatible with "git archive".
The advantage of "git archive" is that the releaser doesn't have to
download the tar ball and extract it, rather the archive is built
directly from the repository. This is probably what GitHub uses
internally to produce the tarballs, so I wouldn't expect a difference.
Reviewed By: tstellar
Differential Revision: https://reviews.llvm.org/D91494
Summary:
Since a full run of test-release.sh takes many hours (at least on my
poor systems), we might as well spend some extra time compressing the
tarball, in return for a quite a bit of gains for uploading and
downloading it.
As an example, the 10.0.0-rc4 .tar.xz tarball shrinks from 465MiB to
306MiB, about 52% smaller.
Reviewers: hans, tstellar, rovka
Reviewed By: hans
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D76192
Konrad Kleine