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 Ulrich Schmidt
> Sent: woensdag 21 mei 2014 16:53
> To: lua-l@lists.lua.org
> Subject: Re: Makefile vs LUA_PATH inconsistency
> 
> 
> 
> 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.

That's how its done now. But I have no problem in renaming `clibs` in the above examples into `lua`, so they mix. That would even allow the trees to be further simplified, to only a version number for example. Eg. !\\5.2\\?.dll and !\\5.2\\?.lua

Thijs