RE: Makefile vs LUA_PATH inconsistency

[Thijs Schreijer <thijs@...>]

> -----Original Message-----
> From: lua-l-bounces@lists.lua.org [mailto:lua-l-bounces@lists.lua.org] On
> Behalf Of Thijs Schreijer
> Sent: woensdag 21 mei 2014 16:16
> To: Lua mailing list
> Subject: RE: Makefile vs LUA_PATH inconsistency
> 
> 
> 
> > -----Original Message-----
> > From: lua-l-bounces@lists.lua.org [mailto:lua-l-bounces@lists.lua.org] On
> > Behalf Of Ulrich Schmidt
> > Sent: woensdag 21 mei 2014 15:24
> > To: lua-l@lists.lua.org
> > Subject: Re: Makefile vs LUA_PATH inconsistency
> >
> >
> >
> > Am 21.05.2014 14:13, schrieb Jay Carlson:
> > > On May 21, 2014, at 7:32 AM, Philipp Janda <siffiejoe@gmx.net> wrote:
> > >
> > >> Am 21.05.2014 13:00 schröbte Thijs Schreijer:
> > >>
> > >> 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 ...
> > >
> > > Which reminds me: should a mingw target be basing these off %HOME%
> and/or
> > All Users? Maybe I've spent too much time around machines without write
> > access to C:\Program Files and written a few too many "Install for all
> > users, or just me" installers.
> > >
> >
> > Simply dont install into c:\programs.
> > 1. you dont know your makefile is used to compile 32/64bit-exe
> > 2. some/many programs become installed into subfolders
> >     of c:\ instead c:\programs to avoid the r/o-trouble.
> >     I did so for my lua for instance.
> >
> > Ulrich.
> >
> 
> Sometimes you don't have a choice. Also; binaries, sometimes remotely
> fetched, are a security risk, and hence they should always go into
> 'C:\Program Files' imo. It's plain sanity that the user must then provide
> proper credentials for access to those locations. Don't try to circumvent
> that.
> 
> First there is the Lua installation (which would require some filetree
> definition);
>  - executables, headers, libs, docs
> 
> Then there are 3 types of paths for the modules;
>  - local to the executables  --> '!\\`
>  - local to the current path --> `.\\`
>  - OS specific paths for application/userdata --> %LOCALAPPDATA%,
> %ProgramFiles% and %ProgramFiles(x86)% (And these would be different for
> Cygwin type installations)
> 
> The last one is most integrated with Windows, but also a can of worms due to
> all the different versions (and 32/64bit).
> 
> So imo the only option is pretty close to the current module paths, sticking
> with current path or executable path, and optionally, with a big bonus using
> the %LOCALAPPDATA% path for a user specific location.
> 

The results would be this;

LUA_PATH
  %LOCALAPPDATA%\\lua\\5.2\\lua\\?.lua;
  %LOCALAPPDATA%\\lua\\5.2\\lua\\?\\init.lua;
  !\\lua\\?.lua;
  !\\lua\\?\\init.lua;
  !\\?.lua;
  !\\?\\init.lua;
  .\\?.lua;
  .\\?\\init.lua;

LUA_CPATH  (using 'clibs' as arbitrary name for binary modules)
  %LOCALAPPDATA%\\lua\\5.2\\clibs\\?.dll;
  !\\clibs\\?.dll;
  !\\?.dll;
  !\\loadall.dll;
  .\\?.dll

The path to %LOCALAPPDATA% must be versioned to prevent conflict, as all Lua versions would be using the same path here. Now if that must be versioned, it would seem silly to not version the other ones. (so through a series of deductions one ends up with a similar structure to the unix flavors).

Reworking that would give;
LUA_PATH
  %LOCALAPPDATA%\\lua\\5.2\\lua\\?.lua;
  %LOCALAPPDATA%\\lua\\5.2\\lua\\?\\init.lua;
  !\\lua\\5.2\\?.lua;
  !\\lua\\5.2\\?\\init.lua;
  !\\?.lua;
  !\\?\\init.lua;
  .\\?.lua;
  .\\?\\init.lua;

LUA_CPATH
  %LOCALAPPDATA%\\lua\\5.2\\clibs\\?.dll;
  !\\clibs\\5.2\\?.dll;
  !\\?.dll;
  !\\loadall.dll;
  .\\?.dll

as a proper Windows structure.