LLVM 3.9?

[SeanTAllen]

I see that the LLVM formulae now installs LLVM 4.0 whereas previously it was LLVM 3.9.

There appears to be no way to install LLVM@3.9 via homebrew although 3.8 and 3.7 are still available.
Is the plan to provide a llvm@3.9 that can be installed?

If yes, is anyone working on that?
If no, is the plan going forward to not provide support for installing older versions of llvm or is this specific to llvm?

[ilovezfs]

@SeanTAllen it's dependent on need and our guidelines for versioned formulae.

Is it the case that neither 3.8 nor 4.0 work for your project(s)?

[SeanTAllen]

We use as part of CI for pony to verify that new changes work for folks who have supported LLVM versions like 3.9 installed. Without a llvm@3.9 (and such going forward), we have to switch to testing against 3.9 and other llvm versions in other ways. We like using homebrew for this as most pony OSX users install llvm via homebrew so we are testing against what they are running.

[ilovezfs]

My general concern about accepting that particular use case as a basis for adding versioned formulae is that it implies we'd provide a versioned formula for every llvm version going forward. At least as they currently stand, that is inconsistent with our guidelines for versioned formulae, which do not stipulate that we'll reflexively provide a versioned formula every time a version becomes no-longer-the-current-version.

One concern I have specifically about 3.9 is that there isn't a release_39 branch here: https://github.com/llvm-project/llvm-project/branches/all so it's not clear whether upstream intends to provide any support for the 3.9.x series going forward.

I had initially included an llvm@3.9 in the llvm 4.0 PR (1fed4b5) but since ponyc built fine against the llvm@3.8 formula, there was no specific need for an llvm@3.9 formula on our end. Also, my version of the formula was inconsistent with the suffixed style of llvm@3.8 and below so it would probably need to be adjusted anyway unless we switched those over to being keg_only :versioned_formulaas well, or decided to tolerate the inconsistency.

[SeanTAllen]

We are turning off testing against 3.9 and looking at how we can avoid depending on homebrew going forward. In the end, homebrew's goals are different than what we need in terms of installing dependencies for CI. Makes sense as what we need are not homebrew's goals.

[neutric]

Hosting a personal tap might be a good alternative for your purposes. All you'd have to do is copy and paste from previous versions of the main llvm formula and do minimal adjustments for the versioned formula format.

[SeanTAllen]

FYI, we just had a bug reopened that appears to only happen with LLVM3.8 (not 3.9). This is something you might want to consider with versioning. End users might suffer when there are bugs in LLVM. So, if there are bugs in LLVM 4.0 that could be avoided by using 3.9, if those versions aren't available, end users will run into issues.

So the change to build ponyc installed via homebrew with llvm 3.8 appears to have introduced a crashing pony runtime bug. Can't guarantee it, but I'm sure this will be an issue with projects that rely on other projects like LLVM.

[ilovezfs]

@SeanTAllen how's ponylang/ponyc#1592 coming along?

[SeanTAllen]

@ilovezfs i'm not personally involved in that. And no guarantees that 4.0 won't introduce crashing bugs where 3.9 didn't have.

[ilovezfs]

We are turning off testing against 3.9 and looking at how we can avoid depending on homebrew going forward. In the end, homebrew's goals are different than what we need in terms of installing dependencies for CI. Makes sense as what we need are not homebrew's goals.

So … do you want a 3.9 or not? I'm not clear now.

[SeanTAllen]

@ilovezfs in an ideal world yes, but it doesn't seem in keeping with homebrew's goals with versioning. Outside of our CI, we are a project that relies on LLVM and LLVM has bugs and sometimes we need to recommend specific LLVM versions like 3.9 to avoid bugs in other versions. Previously, when LLVM 3.8 was introduced, we found a bug in LLVM that caused us to declare LLVM 3.8.0 unsupported and recommended LLVM 3.7.1 until LLVM 3.8.1 came out. It now appears that we have a bug related to LLVM 3.8.1 that isn't in LLVM 3.9.1 I don't think we will be the only LLVM using project that will have such issues. This however is a much larger issue than just having a LLVM 3.9 version available via homebrew. Operating under the assumption that homebrew versioning policies for LLVM won't change, we need to have a Pony core team discussion about our options including maintaining our own LLVM taps.

[ilovezfs]

@SeanTAllen have you considered that you can simply git checkout c596d088ba7d32ffeb5aa361d5278a3d89e64c53 on your CI, and then it will use 3.9?

Regarding the specific issue with 3.8, it sounds like it would work to switch it over to llvm@3.7?

[SeanTAllen]

@ilovezfs we had not considered that re: git checkout. its another option for us to consider. re: 3.7, its a possibility. we need to investigate more.

[ilovezfs]

@SeanTAllen well let us know: #11112

[SeanTAllen]

will do @ilovezfs. thanks. i could have opened that PR if needed. thank you for doing that.

[sylvanc]

I'm afraid I'm a bit baffled. Why is there no desire for homebrew to support an LLVM@3.9? Given how many other projects have many homebrew versions, and how useful it is for compiler projects in general to test against multiple LLVM versions, this seems like something homebrew would want to support.

Perhaps I'm misunderstanding something?

[ilovezfs]

I'd like to see projects at least attempt to move to 4.0 before we conclude there is going to need to be a versioned llvm in Homebrew for every release from now until the end of the universe.

[ts826848]

For what it's worth the official LLVM git remote at http://llvm.org/git/llvm.git does have a release_39 branch. Don't know what's going on with https://github.com/llvm-project/llvm-project/branches/all.

[ilovezfs]

Thanks Alex.

[killerswan]

Beyond specific bugs, I think @tmcdonell's pull request for ADDING llvm@3.9 explained a valid reason for KEEPING it, too:

Additionally, for my own use can, LLVM is one of the dependencies of my software and it requires a specific version to be installed. It is much easier to write in the documentation/installation instructions brew install llvm@3.9; rather than brew install llvm; brew link --force llvm and hope for the best. I think this is a valid use case.

See #9414.

[killerswan]

Also worth mentioning that according to the LLVM project itself, when discussing a change in version scheme (and mentioning the "major releases" 3.8, 3.9, 4.0, and 5.0), "every release is also API breaking".
http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html

[ilovezfs]

None of that is new information specific to 3.9 or our guidelines, but thanks.

[magicgoose]

@ilovezfs numba (python package) currently requires llvm 3.9.x, and it fails with both 4.0 and 3.8.
Simply throwing away 3.9 is not a wise thing to do!

[tmcdonell]

I have versioned formulae here. As @neutric suggested you could similarly host a personal tap with the build configured for your needs. I guess you miss out on bottles, but other than that the tap system is very easy to use.

[ilovezfs]

@tmcdonell I notice that you didn't import the 3.7 formula. Was that for any particular reason?

[tmcdonell]

@ilovezfs I'm currently only testing against 3.8, 3.9, and 4.0 was all. I have no real reason not to import it though. I'll do that now...

[ilovezfs]

@tmcdonell OK, cool. Any thoughts on keg_only vs. versioned binaries for @3.9? Specifically 1fed4b5 vs. https://github.com/tmcdonell/homebrew-llvm/blob/master/Formula/llvm-3.9.rb ? It would be easier for us to basically automate the former but you've already done the work for the latter.

[tmcdonell]

Wait, that first link you posted is broken for me (rebase?). Do you have a different link?

[ilovezfs]

I think I fixed it: 1fed4b5

[tmcdonell]

Hm, for projects that want to build against llvm-3.9 then having only brew_prefix/bin/llvm-config-3.9 for an otherwise key_only should be enough. If they need to call the executables directly for some reason they could find them at llvm-config-3.9 --bindir.

That would be easy to automate and might be enough for a lot of use cases.

[ilovezfs]

Closing this, but we can continue the discussion on #11204.

[ilovezfs]

llvm@3.9 shipped.

[yiakwy]

@ilovezfs llvm@3.9 from homebrew does not support libcxxapi. We need it. Can you show me how to edit llvm@3.9.rb to support the compilation. Here is a example from Homebrew legacy, I don't know how to generate the hash but I am sure this might work.