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