* lua vs luajit vs both @ 2014-01-13 16:03 Jason 2014-01-14 1:02 ` Jason 0 siblings, 1 reply; 5+ messages in thread From: Jason @ 2014-01-13 16:03 UTC (permalink / raw) Hi, What reasons do we have for supporting lua at all? Why not just go with luajit? It's faster and just as widely supported. The motivation for not supporting vanilla lua is this luajit library: http://luajit.org/ext_ffi.html . This would be a nice way of being able to ship scripts without a big comment in the header "you need to have the luacrypto package installed for this to work", and similar. Currently, the tree supports both lua and luajit, but I'm tempted to chop this down to just luajit. Thoughts on this? Jason ^ permalink raw reply [flat|nested] 5+ messages in thread
* lua vs luajit vs both 2014-01-13 16:03 lua vs luajit vs both Jason @ 2014-01-14 1:02 ` Jason 2014-01-14 9:08 ` john 0 siblings, 1 reply; 5+ messages in thread From: Jason @ 2014-01-14 1:02 UTC (permalink / raw) I've gone ahead and merged the lua work to master, for testing and subsequent cleanup before release. Regarding "to jit or not to jit", I currently have this fancy autodetection logic: http://git.zx2c4.com/cgit/commit/?id=3488d124052f5c3ddef303ed5306ad6a458794c1 John -- I'm waiting for your input on the parent email, as you seem to be the originator of the opinion that "both are good". Please -- everybody -- test master and let me know any regressions. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.zx2c4.com/pipermail/cgit/attachments/20140114/0290e74d/attachment.html> ^ permalink raw reply [flat|nested] 5+ messages in thread
* lua vs luajit vs both 2014-01-14 1:02 ` Jason @ 2014-01-14 9:08 ` john 2014-01-14 18:06 ` Jason 0 siblings, 1 reply; 5+ messages in thread From: john @ 2014-01-14 9:08 UTC (permalink / raw) On Tue, Jan 14, 2014 at 02:02:40AM +0100, Jason A. Donenfeld wrote: > I've gone ahead and merged the lua work to master, for testing and > subsequent cleanup before release. > > Regarding "to jit or not to jit", I currently have this fancy autodetection > logic: > http://git.zx2c4.com/cgit/commit/?id=3488d124052f5c3ddef303ed5306ad6a458794c1 > > John -- I'm waiting for your input on the parent email, as you seem to be > the originator of the opinion that "both are good". It was more of a "there doesn't seem much overhead to supporting both, since the API is the same". I think the Makefile should take an approach more like this though: ifdef NO_LUA CGIT_CFLAGS += -DNO_LUA else if defined(USE_LUAJIT) # LuaJIT code goes here else # Lua code goes here endif Basically, use vanilla Lua by default by provide an easy way for users to switch to LuaJIT if they want. ^ permalink raw reply [flat|nested] 5+ messages in thread
* lua vs luajit vs both 2014-01-14 9:08 ` john @ 2014-01-14 18:06 ` Jason 2014-01-14 22:54 ` john 0 siblings, 1 reply; 5+ messages in thread From: Jason @ 2014-01-14 18:06 UTC (permalink / raw) > On Tue, Jan 14, 2014 at 10:08 AM, John Keeping <john at keeping.me.uk> wrote: > It was more of a "there doesn't seem much overhead to supporting both, > since the API is the same". I think the Makefile should take an > approach more like this though: > > ifdef NO_LUA > CGIT_CFLAGS += -DNO_LUA > else if defined(USE_LUAJIT) > # LuaJIT code goes here > else > # Lua code goes here > endif Okay we've got this fancy autodetection logic now. From the README: > If you'd like to compile without Lua support, you may use: > $ make NO_LUA=1 > And if you'd like to specify a Lua implementation, you may use: > $ make LUA_IMPLEMENTATION=JIT > for using the LuaJIT project. Or: > > $ make LUA_IMPLEMENTATION=VANILLA > for the mainline Lua project. If you specify neither implementation, it will > be auto-detected, preferring LuaJIT if both are present. From cgit.mk: > ifdef NO_LUA > LUA_MESSAGE := linking without specified Lua support > CGIT_CFLAGS += -DNO_LUA > else > LUAJIT_CFLAGS := $(shell pkg-config --cflags luajit 2>/dev/null) > LUAJIT_LIBS := $(shell pkg-config --libs luajit 2>/dev/null) > LUA_LIBS := $(shell pkg-config --libs lua 2>/dev/null) > LUA_CFLAGS := $(shell pkg-config --cflags lua 2>/dev/null) > ifeq (JIT,$(LUA_IMPLEMENTATION)) > ifeq ($(strip $(LUAJIT_LIBS)),) > $(error LuaJIT specified via LUA_IMPLEMENTATION=JIT, but library could not be found.) > endif > LUA_MESSAGE := linking with selected LuaJIT > CGIT_LIBS += $(LUAJIT_LIBS) > CGIT_CFLAGS += $(LUAJIT_CFLAGS) > else ifeq (VANILLA,$(LUA_IMPLEMENTATION)) > ifeq ($(strip $(LUA_LIBS)),) > $(error Lua specified via LUA_IMPLEMENTATION=VANILLA, but library could not be found.) > endif > LUA_MESSAGE := linking with selected Lua > CGIT_LIBS += $(LUA_LIBS) > CGIT_LIBS += $(LUA_CFLAGS) > else ifneq ($(strip $(LUAJIT_LIBS)),) > LUA_MESSAGE := linking with autodetected LuaJIT > CGIT_LIBS += $(LUAJIT_LIBS) > CGIT_CFLAGS += $(LUAJIT_CFLAGS) > else ifneq ($(strip $(LUA_LIBS)),) > LUA_MESSAGE := linking with autodetected Lua > CGIT_LIBS += $(LUA_LIBS) > CGIT_CFLAGS += $(LUA_CFLAGS) > else > LUA_MESSAGE := linking without autodetected Lua support > NO_LUA := YesPlease > CGIT_CFLAGS += -DNO_LUA > endif > > endif > > # Add -ldl to linker flags on non-BSD systems. > ifeq ($(findstring BSD,$(uname_S)),) > CGIT_LIBS += -ldl > endif How's this look to you? The correct way to be doing things? ^ permalink raw reply [flat|nested] 5+ messages in thread
* lua vs luajit vs both 2014-01-14 18:06 ` Jason @ 2014-01-14 22:54 ` john 0 siblings, 0 replies; 5+ messages in thread From: john @ 2014-01-14 22:54 UTC (permalink / raw) On Tue, Jan 14, 2014 at 07:06:34PM +0100, Jason A. Donenfeld wrote: > > > > On Tue, Jan 14, 2014 at 10:08 AM, John Keeping <john at keeping.me.uk> wrote: > > It was more of a "there doesn't seem much overhead to supporting both, > > since the API is the same". I think the Makefile should take an > > approach more like this though: > > > > ifdef NO_LUA > > CGIT_CFLAGS += -DNO_LUA > > else if defined(USE_LUAJIT) > > # LuaJIT code goes here > > else > > # Lua code goes here > > endif > > Okay we've got this fancy autodetection logic now. From the README: > > > If you'd like to compile without Lua support, you may use: > > $ make NO_LUA=1 > > And if you'd like to specify a Lua implementation, you may use: > > $ make LUA_IMPLEMENTATION=JIT > > for using the LuaJIT project. Or: > > > > $ make LUA_IMPLEMENTATION=VANILLA > > for the mainline Lua project. If you specify neither implementation, it will > > be auto-detected, preferring LuaJIT if both are present. > > From cgit.mk: > > > ifdef NO_LUA > > LUA_MESSAGE := linking without specified Lua support > > CGIT_CFLAGS += -DNO_LUA > > else > > LUAJIT_CFLAGS := $(shell pkg-config --cflags luajit 2>/dev/null) > > LUAJIT_LIBS := $(shell pkg-config --libs luajit 2>/dev/null) > > LUA_LIBS := $(shell pkg-config --libs lua 2>/dev/null) > > LUA_CFLAGS := $(shell pkg-config --cflags lua 2>/dev/null) > > ifeq (JIT,$(LUA_IMPLEMENTATION)) > > ifeq ($(strip $(LUAJIT_LIBS)),) > > $(error LuaJIT specified via LUA_IMPLEMENTATION=JIT, but library could not be found.) > > endif > > LUA_MESSAGE := linking with selected LuaJIT > > CGIT_LIBS += $(LUAJIT_LIBS) > > CGIT_CFLAGS += $(LUAJIT_CFLAGS) > > else ifeq (VANILLA,$(LUA_IMPLEMENTATION)) > > ifeq ($(strip $(LUA_LIBS)),) > > $(error Lua specified via LUA_IMPLEMENTATION=VANILLA, but library could not be found.) > > endif > > LUA_MESSAGE := linking with selected Lua > > CGIT_LIBS += $(LUA_LIBS) > > CGIT_LIBS += $(LUA_CFLAGS) > > else ifneq ($(strip $(LUAJIT_LIBS)),) > > LUA_MESSAGE := linking with autodetected LuaJIT > > CGIT_LIBS += $(LUAJIT_LIBS) > > CGIT_CFLAGS += $(LUAJIT_CFLAGS) > > else ifneq ($(strip $(LUA_LIBS)),) > > LUA_MESSAGE := linking with autodetected Lua > > CGIT_LIBS += $(LUA_LIBS) > > CGIT_CFLAGS += $(LUA_CFLAGS) > > else > > LUA_MESSAGE := linking without autodetected Lua support > > NO_LUA := YesPlease > > CGIT_CFLAGS += -DNO_LUA > > endif > > > > endif > > > > # Add -ldl to linker flags on non-BSD systems. > > ifeq ($(findstring BSD,$(uname_S)),) > > CGIT_LIBS += -ldl > > endif > > How's this look to you? The correct way to be doing things? I think it does the right thing for all the explicitly specified combinations. Personally I would let the compiler error out if Lua isn't installed, and add some documentation in Makefile to point users at NO_LUA, but I don't feel particularly strongly about that, and since you've done the hard work to make it more intelligent... ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-01-14 22:54 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-01-13 16:03 lua vs luajit vs both Jason 2014-01-14 1:02 ` Jason 2014-01-14 9:08 ` john 2014-01-14 18:06 ` Jason 2014-01-14 22:54 ` john
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).