A topic that creates confusion and a lot of questions is the availability of subproject specific tarballs (i.e. cfe, lld, runtimes etc). They are confusing because most likely you will need to download most of them and “recreate” the monorepo locally in order to build. Standalone builds are not very supported and we keep getting bug reports about them.
- 16.0.3 `libcxx`, `libcxxabi`: circular build dependencies · Issue #55632 · llvm/llvm-project · GitHub
- [bolt] 16.0.5: cmake fails · Issue #63172 · llvm/llvm-project (github.com)
And previous discussion on discourse:
- RFC: Stand-alone build support - #12 by h-vetinari
Reading all these topics it makes the following things are a negative with the stand-alone packages:
- Stand-alone builds are not maintained, some subprojects are “more” maintained than others.
- Building from the subproject tarballs in a release requires a lot of trial-and-error and you need to basically stitch together the mono repo again.
- All these tarballs being part of the release page makes it confusing and hard for beginners to understand what they need to do and that for most people you just have to take
On the positive side:
- Less to download if you only want to build LLVM or Clang.
- Distributions often use these scripts to craft the different subpackages of LLVM and would be hurt by removing them.
In order to solve the confusion and documentation problem my suggestion would be that we still will provide the subproject tarballs, but not upload them in the same place as the release artifacts. I.e. not on the release page in GitHub. This would remove a lot of the confusion around these packages and make it so that beginners wouldn’t get lost when they are selecting what artifact to download. It will take away a lot of the clutter on this page. But the packages would still be available for distributions to rely on and use in their more “advanced” usages.
The big question for this is of course where to put these subproject archives. We could use releases.llvm.org for this or create two releases in github (might be confusing again though) or create a whole new repo on github just to store these artifacts.
I am open to suggestions, but I think this suggestion is at least moving in the right direction from where we are right now.