Currently, in ${TORCH}/install/etc/luarocks/config.lua, luarocks home is set to the user's home directory:

I wonder if this is a contributing factor to all th eissues that people get where the torch luarocks conflicts with a previously installed luarocks? Perhaps the torch luarocks could point to a luarocks home inside the ${TORCH}/install tree?

LuaRocks may add some lines to site_config.lua, like this:

if [ -n "$(MULTIARCH_SUBDIR)" ] ;\
then \
   echo 'site_config.LUAROCKS_EXTERNAL_DEPS_SUBDIRS={ bin="bin", lib={ "lib", [[$(MULTIARCH_SUBDIR)]] }, include="include" }' >> src/luarocks/site_config.lua ;\
   echo 'site_config.LUAROCKS_RUNTIME_EXTERNAL_DEPS_SUBDIRS={ bin="bin", lib={ "lib", [[$(MULTIARCH_SUBDIR)]] }, include="include" }' >> src/luarocks/site_config.lua ;\
fi

Where $MULTIARCH_SUBDIR) is set as follows:

if [ "$LUAROCKS_UNAME_S" = Linux ]
then
   GCC_ARCH=`gcc -print-multiarch 2>/dev/null`
   if [ -n "$GCC_ARCH" -a -d "/usr/lib/$GCC_ARCH" ]
   then
      MULTIARCH_SUBDIR="lib/$GCC_ARCH"
   elif [ -d "/usr/lib64" ]
   then
      # Useful for Fedora systems
      MULTIARCH_SUBDIR="lib64"
   fi
fi

($LUAROCKS_UNAME_S is uname -s)

These lines are not in site_config.lua installed by torch/distro: https://github.com/torch/luajit-rocks/blob/411f4b9d9c4be176d4aab965ebfce50911583e14/luarocks/src/luarocks/site_config.lua.in

This affects ease of linking Lua rocks with libraries installed e.g. in /usr/lib/x86_64-linux-gnu, see daurnimator/lua-http#39 (comment)

I'm using boxen on OSX 10.9 and (for some stupid reason) it puts homebrew in /opt/boxen/homebrew/ instead of the default /usr/local

When I use the torch7 easyinstall script at https://github.com/torch/ezinstall/blob/master/install-luajit%2Btorch I get the following error:

... // See https://github.com/torch/ezinstall/issues/27 for full output
[ 73%] Building ASM object luajit/CMakeFiles/luajit.dir/lj_vm.s.o
Linking C executable luajit
Undefined symbols for architecture x86_64:
  "_rl_completion_suppress_append", referenced from:
      _lua_rl_complete in luajit.c.o
ld: symbol(s) not found for architecture x86_64

I grepped the ./build/CMakeCache.txt file and found it was trying to use the OSX default /usr/lib/libreadline.dylib (which symlinks to libedit) instead of the one I installed and linked with homebrew.

READLINE_readline_LIBRARY:FILEPATH=/usr/lib/libreadline.dylib

To finally fix it, I just symlinked the homebrew lib folder into the place where it usually is (/usr/local/lib) deleted the whole gitfolder and reran the script. Then, all was well and it completed successfully.

My question is how to better handle this use-case? Is there a way to specify the location of the proper file?

luajit 2.1.0 beta has been released some time ago. Are there plans to package it?

Installing with cmake (from cmake.org) and mingw32-make (from mingw-get).

$ git clone https://github.com/torch/luajit-rocks.git
$ cd luajit-rocks
$ mkdir build
$ cd build
$ cmake .. -G "MSYS Makefiles" -DCMAKE_INSTALL_PREFIX=/ljitr
# ... 
# -- Build files have been written to: C:/MinGW/temp/luajit-rocks/build
$ mingw32-make install 
process_begin: CreateProces(NULL, /C/MinGW/bin/cmake.exe -H/C/MinGW/temp/luajit-rocks -B/C/MinGW/temp/luajit-rocks/build --check-build-system CMakeFiles/Makefile.cmake 0, ...) failed.
make (e=2): The system cannot find the file specified. 
Makefile:236: recipe for target 'cmake_check_build_system' failed
mingw32-make: *** [cmake_check_build_system] Error 2

I understand that Torch on Windows is not supported, but the installation section of this repository leads me to believe that there is hope for this much!

Recently we encountered intermittent failures while building luajit in parallel on a build server.
The error diagnostic appeared to be completely misleading (see below). It seemed almost like we missed a dependency to the generated file.
After some digging, I have concluded that generated dependencies are fine - also, should the file with macro definition be missing, first error should have been about that include file not found, unless we have some real bad header eclipsing issues here.
Another plausible explanation would be memory exhaustion that is somehow 'gracefully' handled by the compiler. The log shows that we had 2 huge amalgam files built in parallel.
I think the best way to fix it would be to add direct dependency between liajit and luajit-static targets:

IF(WITH_AMALG)
add_library(libluajit SHARED src/ljamalg.c ${DEPS} )
add_library(luajit-static STATIC src/ljamalg.c ${DEPS} )
set_property(TARGET luajit-static PROPERTY POSITION_INDEPENDENT_CODE 1)
# adding a fake dependency to serialize builds of ljamalg.c that needs memory
add_dependencies(luajit-static libluajit)
ELSE()
....

Another option (to which we have resorted at the moment) is to explicitly serialize make commands in distro/install.sh :
(make 2>&1 luajit-static || exit 1)
(make 2>&1 || exit 1)
(make install 2>&1 || exit 1)

@soumith, please take a look.

Here is the build log showing the issue:

In file included from /opt/torch/exe/luajit-rocks/luajit-2.1/src/ljamalg.c:67:0:
/opt/torch/exe/luajit-rocks/luajit-2.1/src/lj_opt_fold.c: In function 'lj_opt_fold':
/opt/torch/exe/luajit-rocks/luajit-2.1/src/lj_opt_fold.c:2408:18: warning: implicit declaration of function 'fold_hashkey' [-Wimplicit-function-declaration]
uint32_t h = fold_hashkey(k);
^
/opt/torch/exe/luajit-rocks/luajit-2.1/src/lj_opt_fold.c:2409:19: error: 'fold_hash' undeclared (first use in this function)
uint32_t fh = fold_hash[h]; /* Lookup key in semi-perfect hash table. */
^
/opt/torch/exe/luajit-rocks/luajit-2.1/src/lj_opt_fold.c:2409:19: note: each undeclared identifier is reported only once for each function it appears in
In file included from /opt/torch/exe/luajit-rocks/luajit-2.1/src/lj_jit.h:10:0,
from /opt/torch/exe/luajit-rocks/luajit-2.1/src/lj_trace.h:12,
from /opt/torch/exe/luajit-rocks/luajit-2.1/src/lj_gc.c:27,
from /opt/torch/exe/luajit-rocks/luajit-2.1/src/ljamalg.c:31:
/opt/torch/exe/luajit-rocks/luajit-2.1/src/lj_opt_fold.c:2411:29: error: 'fold_func' undeclared (first use in this function)
ref = (IRRef)tref_ref(fold_funcfh >> 24);
.....
make[2]: *** [exe/luajit-rocks/luajit-2.1/CMakeFiles/libluajit.dir/src/ljamalg.c.o] Error 1
make[1]: *** [exe/luajit-rocks/luajit-2.1/CMakeFiles/libluajit.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
make[2]: *** [exe/luajit-rocks/luajit-2.1/CMakeFiles/luajit-static.dir/src/ljamalg.c.o] Error 1
make[1]: *** [exe/luajit-rocks/luajit-2.1/CMakeFiles/luajit-static.dir/all] Error 2
make: *** [all] Error 2

Luarocks looks for the configuration file in ~/.luarocks whereas it is installed into /usr/local/etc/luarocks/. This does break the following Torch installation.

halo.I install with luajit2,but I use openresty(openresty.org),I got the error info: attempt to call global 'ngx_say' (a nil value)

And sorry for my bad english...

When I make and install according to directions, it keeps putting it .../lua/5.1. I want it installed in ../lua/5.3. What am I missing? I only have 5.3.3 installed

Hi, I played with your repo under windows xp, cmake 3.0.2 and msvc 2010 and here are some things I had to do to make it work. Otherwise, very pleasant experience, thanks a lot.

• With this patch, luarocks (built from this repo) runs command line tools correctly

 if detected.windows then
-   local full_prefix = site_config.LUAROCKS_PREFIX.."\\"..cfg.major_version
+   local full_prefix = site_config.LUAROCKS_PREFIX
    extra_luarocks_module_dir = full_prefix.."\\lua\\?.lua"

    for _, var in ipairs(bins) do
       if defaults.variables[var] then
-         defaults.variables[var] = full_prefix.."\\tools\\"..defaults.variables[var]
+         defaults.variables[var] = full_prefix..defaults.variables[var]
       end

• With this dir added (files from torch7-split repo) cmake doesn't complain about files missing in bin. Not sure if all of them are needed, though.

Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        new file:   luarocks/win32/bin/7z.dll
        new file:   luarocks/win32/bin/7z.exe
        new file:   luarocks/win32/bin/chmod.exe
        new file:   luarocks/win32/bin/cp.exe
        new file:   luarocks/win32/bin/find.exe
        new file:   luarocks/win32/bin/libeay32.dll
        new file:   luarocks/win32/bin/libiconv2.dll
        new file:   luarocks/win32/bin/libintl3.dll
        new file:   luarocks/win32/bin/libssl32.dll
        new file:   luarocks/win32/bin/ls.exe
        new file:   luarocks/win32/bin/md5sum.exe
        new file:   luarocks/win32/bin/mkdir.exe
        new file:   luarocks/win32/bin/mv.exe
        new file:   luarocks/win32/bin/objdump.exe
        new file:   luarocks/win32/bin/pwd.exe
        new file:   luarocks/win32/bin/rm.exe
        new file:   luarocks/win32/bin/rmdir.exe
        new file:   luarocks/win32/bin/test.exe
        new file:   luarocks/win32/bin/uname.exe
        new file:   luarocks/win32/bin/wget.exe

With the latest luajit-rocks, torch builds fail with

gcc -O2 -fPIC -I/opt/torch/install/include -c src/lfs.c -o src/lfs.o
src/lfs.c:84:0: warning: "luaL_newlib" redefined
 #  define luaL_newlib(L,l) (lua_newtable(L), luaL_register(L,NULL,l))
 ^
In file included from src/lfs.c:67:0:
/opt/torch/install/include/lauxlib.h:125:0: note: this is the location of the previous definition
 #define luaL_newlib(L, l) (luaL_newlibtable(L, l), luaL_setfuncs(L, l, 0))
 ^
gcc -shared -o lfs.so -L/opt/torch/install/lib src/lfs.o
Updating manifest for /opt/torch/install/lib/luarocks/rocks
No existing manifest. Attempting to rebuild...
luafilesystem 1.6.3-1 is now built and installed in /opt/torch/install/ (license: MIT/X11)

Updating manifest for /opt/torch/install/lib/luarocks/rocks
penlight scm-1 is now built and installed in /opt/torch/install/ (license: MIT/X11)

gcc -O2 -fPIC -I/opt/torch/install/include -c lua_cjson.c -o lua_cjson.o
lua_cjson.c:1312:13: error: static declaration of 'luaL_setfuncs' follows non-static declaration
 static void luaL_setfuncs (lua_State *l, const luaL_Reg *reg, int nup)
             ^
In file included from lua_cjson.c:44:0:
/opt/torch/install/include/lauxlib.h:88:18: note: previous declaration of 'luaL_setfuncs' was here
 LUALIB_API void (luaL_setfuncs) (lua_State *L, const luaL_Reg *l, int nup);
                  ^

Error: Build error: Failed compiling object lua_cjson.o

Looks like it is caused by the following line that was added in one of the latest commits:
https://github.com/torch/luajit-rocks/blob/master/luajit-2.1/src/lauxlib.h#L125

Hi,

please replace in the function 'tools.delete' in file '/luarocks/src/luarocks/fs/win32/tools.lua'
, in the line starting with 'fs.execute_quit', the string "\" with "\*"

Make the same replacement also in the function 'tools.is_dir' in the same source file

The original function does not work, at least on my Windows 7 64-bit system.
See the following comments for more info:

-- bugfix (the original formulation with the '' at the end does not work,
-- it falls incorrectly into the 'directory' path even if the argument is a file
-- The 'rmdir' command then of course gives an error, because it expects a directory and not a file.
-- This error occurs on windows 7, 64-bit - i suppose also on other systems.
-- fix was done according to answer of gerard at http://stackoverflow.com/questions/138981/how-do-i-test-if-a-file-is-a-directory-in-a-batch-script

This commit breaks the build on Windows10(64-bit) with MinGW32(64-bit)

38429af luajit 2.{0,1}: fixing/improving CMakeLists.txt

My Build commands:

mkdir build
cd build
cmake .. -G "MinGW MakeFiles"
mingw32-make

I get errors like these:

C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s: Assembler messages:
C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s: Warning: end of file not at end of a line; newline inserted
C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: invalid character (0x86) in mnemonic
C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: junk at end of line, first unrecognized character valued 0x10
C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: junk at end of line, first unrecognized character is )' C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: junk at end of line, first unrecognized character valued 0xf C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: invalid character (0xb4) in mnemonic C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: invalid character (0xc3) in mnemonic C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: junk at end of line, first unrecognized character is -'
C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: invalid character '' in mnemonic C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: junk at end of line, first unrecognized character valued 0x18 C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: invalid character (0x85) in mnemonic C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: invalid character (0x9d) in mnemonic C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: junk at end of line, first unrecognized character valued 0x6 C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: invalid character '@' in mnemonic C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: junk at end of line, first unrecognized character is 0'
C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: invalid character (0xd9) in mnemonic
C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: invalid character (0xf9) in mnemonic
C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: junk at end of line, first unrecognized character valued 0x1
C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: invalid character '@' in mnemonic
C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: junk at end of line, first unrecognized character is 0' C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: junk at end of line, first unrecognized character valued 0x3 C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: invalid character '@' in mnemonic C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: junk at end of line, first unrecognized character is 0'
C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: invalid character (0x81) in mnemonic
C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: invalid character (0xf2) in mnemonic
C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: invalid character (0xfe) in mnemonic
C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: invalid character (0x81) in mnemonic
C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: invalid character (0xf2) in mnemonic
C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: invalid character (0xfe) in mnemonic
C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: junk at end of line, first unrecognized character valued 0x1c
C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: invalid character (0x81) in mnemonic
C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: invalid character (0xf2) in mnemonic
C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: invalid character (0xfe) in mnemonic
C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: invalid character (0x81) in mnemonic
C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: invalid character (0xf2) in mnemonic
C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: invalid character (0xfe) in mnemonic
C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: invalid character (0xfe) in mnemonic
C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: invalid character (0x83) in mnemonic
C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: junk at end of line, first unrecognized character is `9'
C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: invalid character (0x8b) in mnemonic
C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: invalid character (0xfe) in mnemonic
C:\build\pkg\torchcomponents\luajit-rocks\build22\luajit-2.0\lj_vm.s:1: Error: invalid character (0x83) in mnemonic
mingw32-make[2]: *** [luajit-2.0\CMakeFiles\libluajit.dir\build.make:171: luajit-2.0/CMakeFiles/libluajit.dir/lj_vm.s.obj] Error 1
mingw32-make[1]: *** [CMakeFiles\Makefile2:202: luajit-2.0/CMakeFiles/libluajit.dir/all] Error 2
mingw32-make: *** [Makefile:129: all] Error 2

A bug in luajit.
When executing the following,

torch.Tensor.__gc = function() print('gc') end
tensor = torch.Tensor(10)
-- tensor = nil
-- collectgarbage()

at exit 'gc' will not be printed, however when the last two lines of code are uncommented it will print 'gc'.
Which means at exit collectgarbage is not called by the interpreter.
It is a problem when gc writes log to files, or gc disconnects from a server.

@soumith What's your opinion on this?

When luarocks is run without any arguments, I get this error. The fix is to upgrade luarocks with

luarocks install luarocks

The error:

Error: LuaRocks scm bug (please report at https://github.com/keplerproject/luarocks/issues).
.../manju/torch/install/share/lua/5.1/luarocks/help.lua:77: module 'luarocks.config_cmd' not found:No LuaRocks module found for luarocks.config_cmd
no field package.preload['luarocks.config_cmd']
no file '/home/manju/torch/install/share/lua/5.1/luarocks/config_cmd.lua'
no file '/home/manju/torch/install/share/lua/5.1/luarocks/config_cmd/init.lua'
no file '/home/manju/.luarocks/share/lua/5.1/luarocks/config_cmd.lua'
no file '/home/manju/.luarocks/share/lua/5.1/luarocks/config_cmd/init.lua'
no file './luarocks/config_cmd.lua'
no file '/home/manju/torch/install/lib/lua/5.1/luarocks/config_cmd.lua'
no file '/home/manju/torch/install/lib/lua/5.1/luarocks/config_cmd/init.lua'
no file '/home/manju/torch/install/lib/luarocks/config_cmd.so'
no file '/home/manju/.luarocks/lib/lua/5.1/luarocks/config_cmd.so'
no file '/home/manju/torch/install/lib/lua/5.1/luarocks/config_cmd.so'
no file './luarocks/config_cmd.so'
no file '/home/manju/torch/install/lib/lua/5.1/loadall.so'
no file '/home/manju/torch/install/lib/luarocks.so'
no file '/home/manju/.luarocks/lib/lua/5.1/luarocks.so'
no file '/home/manju/torch/install/lib/lua/5.1/luarocks.so'
no file './luarocks.so'
no file '/home/manju/torch/install/lib/lua/5.1/loadall.so'
stack traceback:
[C]: in function 'require'
.../manju/torch/install/share/lua/5.1/luarocks/help.lua:77: in function <.../manju/torch/install/share/lua/5.1/luarocks/help.lua:44>
(tail call): ?
[C]: in function 'xpcall'
...orch/install/share/lua/5.1/luarocks/command_line.lua:202: in function 'run_command'
/home/manju/torch/install/bin/luarocks:35: in main chunk
[C]: ?

This bug had originally been raised here and they directed it to be filed against this project.

• on windows, my share directory is located directly under $TORCH, rather than in $TORCH/install
• it turns out this is because this directory is determined by $LUA_BINDIR
• and this comes from the rockspec commandline
• which ultimately comes from the luarocks config file
• which comes from ....

  luajit-rocks/luarocks/CMakeLists.txt

  Lines 7 to 22 in 411f4b9

  	IF(WIN32)
  	SET(INSTALL_BIN_SUBDIR "." CACHE STRING "installation executable subdirectory name")
  	SET(INSTALL_LIB_SUBDIR "." CACHE STRING "installation library subdirectory name")
  	SET(INSTALL_LUA_PATH_SUBDIR "lua") # not editable
  	SET(INSTALL_LUA_CPATH_SUBDIR ".") # not editable
  	SET(INSTALL_LUAROCKS_ROCKS_SUBDIR "luarocks" CACHE STRING "installation luarocks rocks subdirectory name")
  	SET(INSTALL_LUAROCKS_SYSCONF_SUBDIR "luarocks" CACHE STRING "installation luarocks sysconfig subdirectory name")
  	ELSE()
  	SET(INSTALL_BIN_SUBDIR "bin" CACHE STRING "installation executable subdirectory name")
  	SET(INSTALL_LIB_SUBDIR "lib" CACHE STRING "installation library subdirectory name")
  	SET(INSTALL_LUA_PATH_SUBDIR "share/lua/${LUA_VERSION}") # not editable
  	SET(INSTALL_LUA_LIB_SUBDIR "lib" CACHE STRING "installation lua lib subdirectory name")
  	SET(INSTALL_LUA_CPATH_SUBDIR "${INSTALL_LUA_LIB_SUBDIR}/lua/${LUA_VERSION}") # not editable
  	SET(INSTALL_LUAROCKS_ROCKS_SUBDIR "lib/luarocks/rocks" CACHE STRING "installation luarocks rocks subdirectory name")
  	SET(INSTALL_LUAROCKS_SYSCONF_SUBDIR "etc/luarocks" CACHE STRING "installation luarocks sysconfig subdirectory name")
  	ENDIF()

IF(WIN32)
  SET(INSTALL_BIN_SUBDIR "." CACHE STRING "installation executable subdirectory name")
  SET(INSTALL_LIB_SUBDIR "." CACHE STRING "installation library subdirectory name")
  SET(INSTALL_LUA_PATH_SUBDIR "lua") # not editable
  SET(INSTALL_LUA_CPATH_SUBDIR ".") # not editable
  SET(INSTALL_LUAROCKS_ROCKS_SUBDIR "luarocks" CACHE STRING "installation luarocks rocks subdirectory name")
  SET(INSTALL_LUAROCKS_SYSCONF_SUBDIR "luarocks" CACHE STRING "installation luarocks sysconfig subdirectory name")
ELSE()
  SET(INSTALL_BIN_SUBDIR "bin" CACHE STRING "installation executable subdirectory name")
  SET(INSTALL_LIB_SUBDIR "lib" CACHE STRING "installation library subdirectory name")
  SET(INSTALL_LUA_PATH_SUBDIR "share/lua/${LUA_VERSION}") # not editable
  SET(INSTALL_LUA_LIB_SUBDIR "lib" CACHE STRING "installation lua lib subdirectory name")
  SET(INSTALL_LUA_CPATH_SUBDIR "${INSTALL_LUA_LIB_SUBDIR}/lua/${LUA_VERSION}") # not editable
  SET(INSTALL_LUAROCKS_ROCKS_SUBDIR "lib/luarocks/rocks" CACHE STRING "installation luarocks rocks subdirectory name")
  SET(INSTALL_LUAROCKS_SYSCONF_SUBDIR "etc/luarocks" CACHE STRING "installation luarocks sysconfig subdirectory name")
ENDIF()

Seems like on purpose LUA_BINDIR is set to . rather than bin on Windows. Before I change this, it seems highly likely this change was done on purpose, so I'm wondering ... why? what are the consequences of making it uniform to the linux version?

I encounter the following behaviour with torch-luajit 2.0.2 / 2.0.3 :

1. Start luajit repl
2. type "a." + double TAB (attempted autocomplete of field of nonexisting table)
3. clear line again
4. CTRL-d (to close)
   -> luajit exits with Segmentation fault (Ubuntu) / Bus error: 10 (OSX)

Notes:

• the Segfault does not occur if the repl is closed via CTRL-c
• the Segfault still occurs if a number of other commands are executed after the unsuccessful autocomplete, before closing the repl

With luajit 2.0.1, I don't seem to have the same issue.

\luajit-rocks\build>nmake install

Microsoft (R) Program Maintenance Utility Version 12.00.21005.1
Copyright (C) Microsoft Corporation.  All rights reserved.

NMAKE : fatal error U1073: don't know how to make 'install'
Stop.

I am unable to nmake install . How to resolve this?

I've just started to re-activate LuaJIT for some experiment stuff, and came across a weirdness:

-- package.path for Lua:          
./?.lua;/Users/cfarabet/tmp/share/lua/5.1/?.lua;/Users/cfarabet/tmp/share/lua/5.1/?/init.lua;/Users/cfarabet/tmp/lib/lua/5.1/?.lua;/Users/cfarabet/tmp/lib/lua/5.1/?/init.lua

-- package.path for LuaJIT:
./?.lua;/Users/cfarabet/tmp/share/luajit-2.0.3/?.lua;/usr/local/share/lua/5.1/?.lua;/usr/local/share/lua/5.1/?/init.lua;/Users/cfarabet/tmp/share/lua/5.1/?.lua;/Users/cfarabet/tmp/share/lua/5.1/?/init.lua

Why would LuaJIT include /usr/local... in its path? Causes some pretty hectic library loading.