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
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
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
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
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
Konrad Kleine