Sam Clegg
Sam Clegg
> What will we do when a feature changes to be incompatible with the stable version of LLVM? Should we error out? Have a branch to handle both the old...
Looks like its happening now: https://github.com/emscripten-core/emscripten/pull/11637 What do you all think about trying to support 11.0 and 12.0 going forward?
One advantage to testing against 11, once it is stable, is that we don't need to build our own versions of LLVM to test it.. we can just use the...
I would imagine that as long its only run a subset of tests we would not claim full support. Once we ditch fastcomp and can do more testing I think...
Perhaps we can add this to the FYI bot along with the contrib ports tree?
You mean do a one off test that verion X.Y of emscripten works with upstream official binaries from A.B of llvm? I guess there is some value in that. Setting...
I'd like to give this a try starting with llvm 11 which is due for release soon. Here is what I think we should try: 1. Start accepting 11 as...
There would be an ongoing cost yes, because we would need to support both stable and tot versions. But divergences should be fairly rare and I imagine will be often...
Apparently llvm 11 was just released so if we want to try your approach perhaps we should tag an emscripten release now to match the llvm release?
Sorry, my bad. LLVM 11 obviously branched a while ago.. ignore me.