Cxx.jl works with Julia 1.1 to 1.3, i.e. no supported version (I put in the warning in the package docs about that).
I was rereading this thread, feeling a bit responsible, thinking I made a PR to the website, seems I didn’t, I’m recalling to Julia’s docs, actually it was for adding CppWrap.jl:
[Yes, I DID drop “Limited support” wording for C++ in that PR, as it seemed pretty unlimited to me, at the time, not knowing all the (future) issues.]
Anyway should Cxx.jl be dropped there and at the website? Is there I light at the end on the tunnel?
I also think Cxx.jl is state-of-the-art and Keno a genius, and sympathetic to needing hacks (unavoidable it seems), since:
From what I read before, Cxx.jl is a dependency of a specific LLVM, and Julia doesn’t want to stay with old one (understandably). There is seems this will always be a potential problem, even if fixed for say 1.7 (is that likely?), then in some newer, e.g. 1.8. If 1.7 ends up being LTS then at least is gives people some time until it potentially breaks again.
This is why:
but it only seems to shift the problem. Could Cxx depend on Cling rather than LLVM? Would that be even more work to “fix” Cxx.jl? Because I really like that option and would want it back!
There’s another thread on a Python package doing similar (with using Cling), other languages too can by now, and even C++ in Jypyther works interactively. While non-ideal (but often a good hack) we could use that Python package, so this is no deal-breaker, except in some very high-performance situations.
One other intriguing possibility: I read elsewhere that LLVM might be dropped as a dependency. Or optionally. That idea was for PackageCompiler.jl in case you need no code generation at runtime. I’m not sure if when you need LLVM, if it would be done as with libtraompoline (for BLAS), i.e. you could load an appropriate LLVM (an older one that works; even for newer Julia that otherwise would use later LLVM, could maybe two LLVMs potentially work?).