lua-users home
lua-l archive

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



Am 21.05.2014 16:47, schrieb Thijs Schreijer:



-----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.




some modules have .lua files AND .dll files. (lualanes for instance)
You want to store them in different subtrees?

Ulrich.