Ports that depend on old llvm versions should be updated

[mf2k (Frank Schima)]

The listed ports depend on older versions of llvm. Can they be updated to use either llvm-3.8 or llvm-3.9?

Originally suggested by jeremyhu in ticket:52317#comment:7.

Port	Maintainers	Status
faust2-devel	ryandesign aggraef
ghc	cal	#48899
julia	sean
pure	ryandesign aggraef
py-llvmlite	stromnov	Not needed
py-llvmpy	stromnov

[ryandesign (Ryan Carsten Schmidt)]

I haven't looked at pure in awhile, but last I checked, there were reasons why I did not want to upgrade pure to a newer version of llvm than 3.4.

For faust2-devel, I don't recall.

I'm not wild about more portgroups and more variants.

[jeremyhu (Jeremy Huddleston Sequoia)]

Yeah, I'd prefer to not have more portgroups, especially for such a small set of projects, some of which are possibly dead and just in need of removal.

[neverpanic (Clemens Lang)]

For GHC, this will be #48899. I am not going to add variants, and I do not prefer using variants due to the additional testing effort I have to do.

[mf2k (Frank Schima)]

I updated the description to remove the mention of variants and a new portgroup due to unpopular demand.

[agraef (Albert Graef)]

I'm the principal developer of Pure, and I also maintain the related ports here (together with Ryan Schmidt).

Pure certainly isn't dead, I just haven't gotten around porting it to LLVM 3.6+ yet. It should work fine with LLVM 3.5, though.

This will also affect all LLVM applications which still rely on the old JIT rather than the new MCJIT of LLVM (of which there are still a few at least in Linux, not so sure about macOS). That's also why LLVM 3.5 ist still supported, e.g., on Arch Linux, along with the latest LLVM version. I'd suggest that MacPorts do the same, if possible. Otherwise supporting Pure on macOS will become *very* hard until it's ported to LLVM 3.6+ (which isn't trivial because of architectural changes in the LLVM JIT, otherwise I would have done it long ago).

Anyway, the executive summary is: I will try to port Pure to LLVM 3.6+ asap, but I'd appreciate it if MacPorts could have LLVM 3.5 stick around a little while until it's done.

[agraef (Albert Graef)]

Concerning faust2-devel, the latest git sources should support both LLVM 3.8 and 3.9, but I haven't verified this myself. I will update that port asap, but this may still take some time as I'm currently busy with other things.

[ryandesign (Ryan Carsten Schmidt)]

Replying to aggraef@…:

Pure certainly isn't dead, I just haven't gotten around porting it to LLVM 3.6+ yet. It should work fine with LLVM 3.5, though.

This will also affect all LLVM applications which still rely on the old JIT rather than the new MCJIT of LLVM (of which there are still a few at least in Linux, not so sure about macOS). That's also why LLVM 3.5 ist still supported, e.g., on Arch Linux, along with the latest LLVM version. I'd suggest that MacPorts do the same, if possible. Otherwise supporting Pure on macOS will become *very* hard until it's ported to LLVM 3.6+ (which isn't trivial because of architectural changes in the LLVM JIT, otherwise I would have done it long ago).

Anyway, the executive summary is: I will try to port Pure to LLVM 3.6+ asap, but I'd appreciate it if MacPorts could have LLVM 3.5 stick around a little while until it's done.

The reason for this ticket is probably the fact that llvm < 3.7 does not build on macOS Sierra. I don't imagine there are any plans to remove llvm < 3.7 for previous verisons of OS X, but also probably no plans to make llvm < 3.7 work on Sierra.

I think the reason why I did not update the port to llvm 3.5 is that that llvm 3.5 and later requires libc++, which is a bit problematic on OS X < 10.9 where libc++ is not the default and much more problematic on Mac OS X < 10.7 where libc++ is not present. Perhaps by now support for older OS versions is less important.

[stromnov (Andrey Stromnov)]

• py-llvmpy has been officially deprecated and is no longer being actively developed (in favor of llvmlite project)
• py-llvmlite strongly depends on LLVM-3.8

[jeremyhu (Jeremy Huddleston Sequoia)]

Pure certainly isn't dead

Sorry if I wasn't clear. I wasn't saying that all the ports are dead and should be removed, just that some are likely in that camp (eg: py-llvmpy as mentioned above).

Don't worry, I do not intend to remove llvm-3.5 unless there are no dependents.

My thoughts on the older versions we still have around:

• 3.3 - Needed for bootstrapping on Leopard. We should limit our dependency elsewhere.
• 3.4 - A very solid release and the last one that works with libstdc++ (needed to bootstrap later versions). It will be around for quite some time.
• 3.5 - codegen issues on i386 make me not trust this version very much. I'd like to remove it eventually (but it is not pressing)
• 3.6 - A decent release, but there's not much of a need for it given the quality of later versions.
• 3.7 - The last release using autoconf. It'll be good to keep this one around as a point of reference for build system related regressions. It's also a high quality release.

[ryandesign (Ryan Carsten Schmidt)]

Replying to jeremyhu@…:

• 3.4 - A very solid release and the last one that works with libstdc++ (needed to bootstrap later versions). It will be around for quite some time.

Did you encounter a particular problem with 3.4 on Sierra, or did you just block it out of habit?

[jeremyhu (Jeremy Huddleston Sequoia)]

Did you encounter a particular problem with 3.4 on Sierra, or did you just block it out of habit?

Yes, the older versions of clang don't support 10.1x deployment targets (so that's actually an issue with Yosemite+), nullable, and various other keywords that are prevalent throughout the newer SDKs.

So it's not so much a "this doesn't work on Sierra" as a "this doesn't work well with the Sierra SDK"

[ryandesign (Ryan Carsten Schmidt)]

Sounds like you're talking about clang. What about just the features of llvm that Dr Graef mentioned he uses in pure?

[jeremyhu (Jeremy Huddleston Sequoia)]

Correct, llvm core is not impacted by the SDK changes, only clang.

[agraef (Albert Graef)]

jeremyhu, thanks for clarifying! I'm certainly glad that LLVM 3.4 will still be supported for the time being, on the older platforms at least.

Concerning clang in Sierra, AFAICT neither Pure nor any of its addon modules have clang as a dependency (other than that they need a C/C++ compiler to build, of course).

Some of the examples that ship with the Pure sources need a C/C++ compiler capable of producing LLVM bitcode, but that's in no way essential, so most Pure users should be fine as long as LLVM 3.4 (or 3.5) is provided, even if there's no matching clang version on Sierra.