llvm-lua is a JIT and static Lua compiler that uses LLVM as the compiler backend. Replacement for dev-lang/lua can also be built (with USE=nojit) Reproducible: Always Steps to Reproduce:
Created attachment 253993 [details] dev-lang/llvm-lua-1.3.1
Created attachment 253995 [details] Patch to get rid of "no-jit" libraries when USE-flag "nojit" is disabled
(In reply to comment #1) > Created an attachment (id=253993) [details] > dev-lang/llvm-lua-1.3.1 > It is bad practice to apply a patch based on useflag.
(In reply to comment #3) > It is bad practice to apply a patch based on useflag. > Is it because failure to apply patch may be unnoticed by maintainer? OK, maybe it's good idea to remove those "no-jit" libraries unconditionally.
Created attachment 258601 [details] removed use-flag "nojit"
DEPEND=">=sys-devel/llvm-$LLVM || ( >=sys-devel/clang-$LLVM >=sys-devel/llvm-gcc-$LLVM )" There is no llvm-gcc in Portage - where do you have that from? Also the website says: "Clang or llvm-gcc 4.2.x from LLVM 2.8 release." So I assume the version should be 4.2 and not 2.8? Further I suggest renaming the LLVM variable to LLVM_VERSION and putting it right at the top - even before MY_PN.
(In reply to comment #6) > DEPEND=">=sys-devel/llvm-$LLVM" P.S: There was llvm-3.1 released in the meantime - does llvm-lua still work with that?
(In reply to comment #6) > There is no llvm-gcc in Portage - where do you have that from? It was there until December 2011. > Also the > website says: "Clang or llvm-gcc 4.2.x from LLVM 2.8 release." So I assume > the version should be 4.2 and not 2.8? In-tree versions were equal to those of LLVM. > Further I suggest renaming the LLVM variable to LLVM_VERSION and putting it > right at the top - even before MY_PN. Do it if you are interested. I personally found llvm-lua to be inferior to luajit-2 (unless a script calls each cpu-hungry function only once, which is not my case). There are other problems with this ebuild that you might want to fix. First, it installs to /usr/local instead of /usr. Second, a patch that gets rid of conflicts with vanilla lua is very rough. You might want to rewrite it. For example, the patch seems to make it impossible to build a script into static binary. It may be a bug in llvm-lua itself, though. Third, development of llvm-lua seems to be stopped, and I don't know if it supports newer LLVM.
(In reply to comment #8) > (In reply to comment #6) > > Further I suggest renaming the LLVM variable to LLVM_VERSION and putting it > > right at the top - even before MY_PN. > > Do it if you are interested. I personally found llvm-lua to be inferior to > luajit-2 (unless a script calls each cpu-hungry function only once, which is > not my case). I have tested neither in practice yet. But thanks for that info! > There are other problems with this ebuild that you might want to fix. First, > it installs to /usr/local instead of /usr. Will fix that. Thanks for the hint! > Second, a patch that gets rid of > conflicts with vanilla lua is very rough. You might want to rewrite it. For > example, the patch seems to make it impossible to build a script into static > binary. It may be a bug in llvm-lua itself, though. That is the nojit patch? [1] is a try to improve it. > Third, development of > llvm-lua seems to be stopped, and I don't know if it supports newer LLVM. It does not. 1.3.1 supports 2.8, current master supports 2.9 (but not 2.8) and 3.0/3.1 are not supported at all. [1] http://code.google.com/p/llvm-lua/issues/detail?id=15
Looks like this is dead upstream. Last commit 2012, around LLVM 3.0. I'm pretty sure it won't work with modern LLVM versions.
