Can we add a short test that runs llvm-config and checks that it doesn't output things like -llibxml2.tbd? see #62480

ccls and castxml each need a revision bump (a separate commit for each, please)

Can we add a short test that runs llvm-config and checks that it doesn't output things like -llibxml2.tbd? see #62480

Lemme see what I can figure out.

ccls and castxml each need a revision bump (a separate commit for each, please)

@fxcoudert done in revised 127f06b. Lemme know if it makes sense though since I'm not very proficient in Ruby.

I still get the -llibxml2.tbd issue :(

I still get the -llibxml2.tbd issue :(

With LLVM 11? Huh, interesting cause I don't. We'll see if the test case passes in the CI.

Yep, with LLVM 11, just compiled using your Formula. This is using Xcode 12.2 beta on Big Sur, though.

Yep, with LLVM 11, just compiled using your Formula. This is using Xcode 12.2 beta on Big Sur, though.

If the CI passes fine here, I reckon it'd be a good idea to inform upstream LLVM of the issue on Big Sur.

Regarding LLVM 11.0.0. They are aware about it AFAIK

Also note that the changes are not likely to be backported to 11 [..]. There should be enough time for 11.0.1, though.
https://reviews.llvm.org/D87590#2273743

Regarding LLVM 11.0.0. They are aware about it AFAIK

If there is a patch, we can consider it. But we need to know that it works, that upstream is considering it.

@jedisct1 @fxcoudert so it seems that my machine must be special, or perhaps I have something (mis)configured in a very special way; the -llibxml2.tbd regression is still there. What do you think the next steps should be? Should we merge this commenting out the test case and wait for the patch from upstream (after confirming with LLVM maintainers that it will happen first)?

The patch is pretty short and simple.

If we can confirm that it works, maybe we should include it, no matter if this is the exact code that will eventually get merged upstream.

And we can always update the patch later if needed.

We should really take the upstream patch unless it's impossible and/or upstream is unwilling to fix it.

I think special big thanks is due to the Homebrew team for working with the Zig folks so quickly and efficiently! It's quite heartening to see it in fact.

Why was libcxxabi added to the runtimes?

What do you mean? The previous formula already did that however only for HEAD with a note to check when llvm-11 is released.

Why was libcxxabi added to the runtimes?

What do you mean? The previous formula already did that however only for HEAD with a note to check when llvm-11 is released.

Sorry, missed the note...

Does anyone know if it is possible to apply a series of patches after all resource blocks are downloaded and extracted into the tree? This way I could leave the patches as they are while reverting back the formula to downloading all llvm components separately which should fix the CI.

If you need to patch a resource I believe the patch block works inside the resource block too. Does that help?

If you need to patch a resource I believe the patch block works inside the resource block too. Does that help?

Unfortunately, it won't. The issue here is that we need to have all components in place before we apply the patches. In other words, first, we need to download llvm-src, clang-src, etc., extract them into one common dir, and then we can apply the patches since the patches are messy and touch upon multiple subprojects in one diff.

OK, nvm, the hashes of diffs changed after I added full_index=1. Correcting now.

downloading all llvm components separately which should fix the CI

What is the problem with CI and llvm-project?

downloading all llvm components separately which should fix the CI

What is the problem with CI and llvm-project?

False alarm :-) I thought we hit the GitHub rate limit but it was my oversight with the hashes of the patches. It should be fixed now. Sorry for confusion!

Yay, everything passed! I reckon we're good to go if you agree! :-)

Woo-ooh!

Many thanks for the collective work on this one!

@fxcoudert has triggered a merge.

I noticed that llvm@10 will be dropped with this PR as is

Correct, unless we have other formulas that strictly depend on LLVM 10 (and won't build with 11), which does not look like it's the case. We do not intend to carry every version of the software, especially when it is not maintained anymore.

I would like to chime in here to point out that the removal of llvm@10 has temporarily broken some users' development environments such as my own. Due to LLVM versions not being fully compatible with each other I pin my environments to specific versions of dependencies and then upgrade them when I have the available time to debug issues that occur due to the upgrade. Right now my environments are pinned by llvm@10 but it's no longer available, preventing me from installing a new environment on another system, or even rolling back if an upgrade to llvm@11 fails.

Currently llvm@9, llvm@8, llvm@7, and llvm@6 are already still available which means the removal of llvm@10 also goes against precedence.

I would like to propose that older versions of LLVM, and potentially other packages used by developers, are kept around at least for a few months so that the above issues are not encountered by users.

Although I do admit that maybe I shouldn't be using Homebrew for this particular use case in the first place as it may be out of Homebrew's scope. Users that version pin could just use the official builds directly instead of going through Homebrew. This is what I do on other platforms anyway.

Our criteria for versioned formulas are set out here: https://docs.brew.sh/Versions
If you believe LLVM 10 meets these criteria, feel free to open a pull request.

Thank you for your response. The linked document clearly states that my use case of version pinning is not in Homebrew's scope which means there is no need to add LLVM 10 back.

Currently llvm@9, llvm@8, llvm@7, and llvm@6 are already still available which means the removal of llvm@10 also goes against precedence.

Rules change constantly based on new insights. Past results do not guarantee an outcome for the future in the case of Homebrew formulae.