On 27 June 2013 01:13, Gary V. Vaughan <g...@vaughan.pe> wrote: > Hi Hisham, > > On 27 Jun 2013, at 03:33, Hisham <h...@hisham.hm> wrote: >> On 25 June 2013 23:30, Gary V. Vaughan <g...@vaughan.pe> wrote: >>> LUA_PATH=$LUA_PATH;`luarocks path` >>> LUA_CPATH=$LUA_CPATH;`luarocks cpath` >> >> I just pushed new flags to `luarocks path` that will hopefully serve your >> needs: >> >> luarocks path --lr-path >> luarocks path --lr-cpath >> luarocks path --lr-bin >> >> Please give it a try and let me know if it's sufficient. > > That approach will definitely make writing wrapper scripts *much* simpler, > thanks! > > However, I think the implementation is still not quite right... > > $ luarocks path > export > LUA_PATH='/usr/local/share/lua/5.1/?.lua;/usr/local/share/lua/5.1/?/init.lua;/Users/gary/.luarocks/share/lua/5.1/?.lua;/Users/gary/.luarocks/share/lua/5.1/?/init.lua;/usr/local/Cellar/luarocks/HEAD/share/lua/5.1//?.lua;/usr/local/Cellar/luarocks/HEAD/share/lua/5.1//?/init.lua;./?.lua;/usr/local/lib/lua/5.1/?.lua;/usr/local/lib/lua/5.1/?/init.lua' > export > LUA_CPATH='/usr/local/lib/lua/5.1/?.so;/Users/gary/.luarocks/lib/lua/5.1/?.so;./?.so;/usr/local/lib/lua/5.1/loadall.so' > > $ luarocks path --lr-path > /usr/local/share/lua/5.1/?.lua;/usr/local/share/lua/5.1/?/init.lua;/Users/gary/.luarocks/share/lua/5.1/?.lua;/Users > > Note that --lr-path omits the paths to the actual luarocks lua files from > /usr/local/Cellar/luarocks/HEAD/share/lua/5.1/?.lua, so when executing a > wrapper script using a different Lua version than the one LuaRocks was > installed with, the luarocks sources can't be found. For example: > > $ cat $LUAROCKS_CONFIG > rocks_trees = { "/usr/local/lib/luarocks/rocks-5.2" } > variables = { > LUA = "/usr/local/opt/lua52/bin/lua5.2", > LUA_BINDIR = "/usr/local/opt/lua52/bin", > LUA_INCDIR = "/usr/local/opt/lua52/include/lua-5.2", > LUA_LIBDIR = "/usr/local/opt/lua52/lib", > } > $ lua5.2 "`which luarocks`" path --lr-path > /usr/local/lib/luarocks/rocks-5.2/share/lua/5.2/?.lua;/usr/local/lib/luarocks/rocks-5.2/share/lua/5.2/?/init.lua
Yes, it is reporting only paths from rocks_trees. The idea would be that this would be the minimal list that's able to load installed modules. I'm not convinced if it should report the LuaRocks sources path itself (which you shouldn't actually need to use modules installed by LR). And even if I added that then some might also complain about the order. If you're already launching things using a custom wrapper, then maybe you should add that explicitly? Another option is to install LuaRocks using "make bootstrap", which installs LR itself as a rock. (I haven't tested that much, but feedback is welcome.) >>> At a slight tangent, 'export foo=bar' is not as portable as 'export foo; >>> foo=bar' >>> which works in pure Bourne shells (on machines that don't just link it to >>> bash). >> >> Is that still the case on any contemporary system? I haven't received >> any bug reports. > > Arguably, not. It's possible to build a basic Solaris system where /bin/sh > is not a posix shell (though I haven't checked whether it specifically omits > `export foo=bar` functionality), but more importantly there are more likely > to be embedded systems that want to use Lua, but don't have the resources for > a full blown bash/zsh/ksh installation. Admittedly, these are edge cases at > best, but it's so trivially simple to support those systems too (by changing > to `export foo; foo = bar` syntax) that it seems like a shame not to do it. Even in embedded systems, tiny shells like ash from busybox and the like already support `export foo=bar`. Supporting archaic cruft is how we end up with things like configure scripts that are over 100k in size... :-) -- Hisham http://hisham.hm/ ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Luarocks-developers mailing list Luarocks-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/luarocks-developers