Tags corresponding to LLVM releases about llvm-bazel

[GMNGeoffrey]

Good idea 🙂 We are developing so closely against LLVM that we don't really use releases, but I can understand why some people might. Your analysis of why we don't have a tag for this is correct.

That said, as I commented on that other issue, we're planning to move the contents of this repository upstream to the LLVM monorepo (https://github.com/llvm/llvm-www/blob/main/proposals/LP0002-BazelBuildConfiguration.md) in a side directory, so the precise mechanism for getting build files for the release would change (the current automation with the tags is pretty hacky and I haven't tried to productionize it because of the upstreaming hopes). There was some discussion of what this would mean for releases, but since no one had a use case we didn't go into too much detail. Whatever it was, it couldn't add to the burden of the release manager, since this is not going to be a supported part of the LLVM project, but I bet we could work something out if you've got a use case.

You can read some of the discussions linked from that proposal (personally I find it much easier to read them on https://groups.google.com/g/llvm-dev rather than pipermail) as well as the review for the patch: https://reviews.llvm.org/D94451

I really need to add that to the README...

[mmcloughlin]

I bet we could work something out if you've got a use case

I guess I assumed releases are more stable/robust than random commits on main? Isn't that what people usually use releases for?

Anyway, yes, not really worth fixing this since the end goal is in-tree build files.

I'm assuming if I want to do this I could try building the LLVM release tag against a nearby commit in llvm-bazel and hope for the best? Or do they need to match exactly?

[GMNGeoffrey]

Yeah I can certainly imagine the reasonable use cases 🙂 I just don't have a ton of interest in doing the work unless there's someone who does use releases who wants this functionality (it's unclear to me if you're saying that you use releases). We update the version of LLVM we're using ~daily because we're actively developing against it (and contributing patches upstream), so we don't have a use for release-specific build files.

I'm assuming if I want to do this I could try building the LLVM release tag against a nearby commit in llvm-bazel and hope for the best? Or do they need to match exactly?

The tags are really just a convenience to allow getting the "best known" build files for a given llvm commit without having to do a bunch of work. Assuming you're getting your copy of LLVM from somewhere other than the submodule within llvm-bazel (e.g. your own submodule or fetching an http_archive with Bazel) then there's nothing tying a given llvm-bazel commit to an llvm-project commit. And if you're only updating once per release or so, then it's not a big deal to manually find the right set of build files (including potentially forking to add some updates or using the http_archive patch mechanism). All this automation is really to support the use case of someone updating all the time. If I were to add build files for the release to this repository, I would probably just create a branch for it and call it good. In fact, if this ends up blocking you before we get these upstream and you figure out what the build files need to look like for the llvm 11 release, I'd be happy to make that a branch on this repo. As a starting point, I'd choose the commit that was the base for the release before any cherry picks and see if the corresponding llvm-bazel commit works for that.

[mmcloughlin]

As for our use case, we're not actively developing against LLVM. We use it for eBPF, and some custom LibTooling based tools. I think for us a release version makes sense. And we're using llvm-bazel rather than a release tarball because we have a policy to build all third-party dependencies from source where possible.

Yes I'm perfectly happy to figure this out for one release. I just thought I'd raise an issue because I assumed others might have the same use case.

Thanks!

[GMNGeoffrey]

With the move of the build files upstream, this is obsolete. Having build files in a release meet some quality standard is something that could be brought up with the community overall, if desired.