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

Reply via email to