RFC: Explaining release package types and purposes

I just answered a question on Discord about why the user could not find llvm-config after installing the LLVM build for Windows on Arm. I also saw folks trying to install Flang from the llvm 20 release confused as to which of the N files listed they should download.

I’ve looked around and GitHub doesn’t provide us any way to add descriptions to release artifacts, the best we could do is name them differently. That gets fiddly, I wonder if some basic suggestions would help folks.

So I wonder if we should give some basic advice where we currently have “A note on binaries”? - Release LLVM 20.1.1 · llvm/llvm-project · GitHub

Or we could document this in How To Release LLVM To The Public — LLVM 21.0.0git documentation or a related page, then link to it.

(either of which I can spend my own time writing, but want to get a good set of information first)

Some basic rules I came up with:

  • If the package is “LLVM-” then it’s a binary release of all of LLVM, for the platform at the end of the file name. LLVM-20.1.1-Linux-ARM64.tar.xz → LLVM binaries for Linux Arm64. Most people will want one of these.
  • If the package is “clang+llvm-” then it’s a binary release for the platform at the end of the filename.
  • Anything *.src.* is an archive of the sources of the named sub-folder of llvm-project for this release (aside from the test-suite which is of llvm-test-suite).
  • If you want the whole of llvm-project for this release, download the “Source code” package, in whichever format you need.
  • Some binary packages are automatically built, so every release will have them, some are made by volunteers, so some releases will not have them or may not have them yet.
  • If you need a very specific build, get it from your distro’s package manager or build your own releases.

Are any of these wrong?
Are there other tips that would be useful?
What else have you been confused by when choosing a release package?
Are there other projects on GitHub that have addressed this in another way?

FYI @tstellar @tobiashieta

  • Community built releases can be found on the third party binaries thread.

(which would be LLVM 20.x Release Third-Party Binaries for 20.x)

+1 I think this is the best place to document what’s in the different files.

In the case of Windows, which has a “LLVM-” and a “clang+llvm-”, the “clang+llvm-” includes libraries and llvm-config, where the “LLVM-” installer does not.

Maybe one way to slice it is by file extension: If it’s an .exe file, it’s a Windows installer focused on shipping a Clang toolchain: it contains clang, lld, runtimes etc. for common Windows target architectures, but not llvm-config, opt, and so on. @omjavaid has a patch out to include Flang here too.

clang+llvm-... includes what’s in the installer plus all the libraries and “non-toolchain” tools (LLVM_INSTALL_TOOLCHAIN_ONLY=OFF).

https://github.com/llvm/llvm-project/pull/138144 to do this.

I also realised that we can predict what the URLs of certain automatically created builds are, so we could have specific links like “Linux / Mac / Windows” up front, but I don’t want to get into that right now. So I’ve just done the documentation bit.

The above PR just went in.

[llvm][release] Add links to automatically built packages on release page by DavidSpickett · Pull Request #147021 · llvm/llvm-project · GitHub proposes adding links to the most common packages.