Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/utils/release/export.sh | ||
---|---|---|
56 | When I was thinking about this, I figured maybe we should just ship llvm-project.tar.xz and test-suite.tar.xz, rather than split up into the old project structure? It seems odd in a way to release in a format that doesn't match the code layout used by developers. Do you think the llvm-projects.tar.xz tarball would be prohibitively large? Or that the change is too large for users of the release? |
llvm/utils/release/export.sh | ||
---|---|---|
56 | If we distributed a single tarball, that would be easy, because GitHub creates one for us and adds it to the list of release assets. The gz compressed file generated by GitHub is 108M. However, as a distro packager, I prefer having the separate tarballs because that's what we use for building packages on Fedora and RHEL. @mgorny, @sylvestre.ledru Do you have any thoughts about this? |
llvm/utils/release/export.sh | ||
---|---|---|
56 | For Debian & Ubuntu, I moved to a single tarball containing it all. Splitting tarballs doesn't bring much values compare to the maintenance cost. BTW, using xz, the tarball is only 72M for 9.0.0 |
llvm/utils/release/export.sh | ||
---|---|---|
56 | I see. I don't have strong opinions about this, but I always assumed that the non-monorepo layout build would go away at some point after the migration. Maybe we should release both an llvm-project.tgz "monorepo tarball" and the separate ones for a while? |
llvm/utils/release/export.sh | ||
---|---|---|
56 | I would prefer split tarballs. There is still a vast number of Gentoo systems whose users interface with LLVM only through Mesa dependencies, and they only need the main LLVM component (and no clang, in the more common case). |
llvm/utils/release/export.sh | ||
---|---|---|
56 | If we want to release an llvm-project tarball, should we have this script generate one or just go with what GitHub gives us[1] Pros of relying on GitHub is it's easier and then we avoid having 2 source tarballs on the GitHub releases page (you can't remove the GitHub generated one). Cons of GitHub is that it uses .tar.gz, so it's bigger than an xz compressed file. 108M vs 72M. [1] https://github.com/llvm/llvm-project/releases/tag/llvmorg-8.0.1 (The "Source Code" links) |
llvm/utils/release/export.sh | ||
---|---|---|
56 | Don't forget that git archive tarballs are not guaranteed to be stable. Their checksums occasionally change (when GitHub upgrades git, I think) and break everything relying on them. |
llvm/utils/release/export.sh | ||
---|---|---|
56 | Non-stable tarballs doesn't sound so good. Another con of GitHub's is that I guess we can't sign them. Or if we do, and the GitHub one changes, the signature won't match. I would prefer us uploading .tar.xz's and .sig's both for the separate projects, and one for llvm-project. |
Build result: pass - 60481 tests passed, 0 failed and 726 were skipped.
Log files: console-log.txt, CMakeCache.txt
lgtm conceptually, just wondering how the "mv" i commented about works.
llvm/utils/release/export.sh | ||
---|---|---|
58 | It looks like there's only one argument to the mv command. Or is there some bash magic here that makes it work? |
llvm/utils/release/export.sh | ||
---|---|---|
58 | This expands to: mv $llvm_src_dir/$pro j $llvm_src_dir/$proj -$release$rc.src |
llvm/utils/release/export.sh | ||
---|---|---|
58 | I can change it if you think it makes it more readable. |
llvm/utils/release/export.sh | ||
---|---|---|
58 | Yes please, even if the expansion is cool (and I want to learn more about these), I think the explicit version is better for readability. |
When I was thinking about this, I figured maybe we should just ship llvm-project.tar.xz and test-suite.tar.xz, rather than split up into the old project structure?
It seems odd in a way to release in a format that doesn't match the code layout used by developers. Do you think the llvm-projects.tar.xz tarball would be prohibitively large? Or that the change is too large for users of the release?