lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


> -----Original Message-----
> From: lua-l-bounces@lists.lua.org [mailto:lua-l-bounces@lists.lua.org] On
> Behalf Of Philipp Janda
> Sent: woensdag 21 mei 2014 13:33
> To: lua-l@lists.lua.org
> Subject: Re: Makefile vs LUA_PATH inconsistency
> 
> Am 21.05.2014 13:00 schröbte Thijs Schreijer:
> >
> > The current 'luaconf.h' defaults for LUA_PATH and LUA_CPATH, dictate most
> of this already (unless you change them too).
> >
> > The defaults currently are (added linebreaks for readability);
> > LUA_PATH
> >    !\\lua\\?.lua;
> >    !\\lua\\?\\init.lua;
> >    !\\?.lua;
> >    !\\?\\init.lua;
> >    .\\?.lua"
> >
> > LUA_CPATH
> >    !\\?.dll;
> >    !\\loadall.dll;
> >    .\\?.dll
> 
> The paths relative to the executable are nice for programs embedding
> Lua, but I'm not sure they are suitable/enough for the standalone Lua
> interpreter. E.g. I often install lua52.exe and lua51.exe in the same
> directory (together with some other command line tools), and there may
> be cases (external package managers, limited privileges) where you can't
> or don't want to write to the Lua installation directory ...

Imo main question here is where to version in the path

{ROOT}
  +- 5.2 + lua.exe
         +- lua
         +- lib

Etc. Or something like;

{ROOT}
  + lua52.exe
  +- lua
  |   +- 5.1
  |   +- 5.2
  +- lib

Etc.

I don't have a preference on this. The former seems simpler as it doesn't mix stuff, and doesn't version the PATH variables (in `luaconf.h`). And so it appears that I do have a preference...

> 
> >
> > What struck me was that it seems that `.\\?\\init.lua` is missing from
> LUA_PATH ? or is there a specific reason?
> 
> It's there in Lua 5.3work2.
> 
> >
> > What I don't like is that the CPATH does not allow for a separate folder
> for the binary modules (even if it just were /lua/, as there is no problem
> in mixing .dll and .lua files).
> 
> Me too, because the base directory will often be in PATH, and if you put
> binary modules there, those will take part in the normal DLL lookup for
> all programs.
> 
> Philipp
> 
>