Makefile vs LUA_PATH inconsistency

classic Classic list List threaded Threaded
73 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Makefile vs LUA_PATH inconsistency

Thijs Schreijer
When building Lua using MinGW, the following structure is produced;

{root}
  +-- bin
  +-- include
  +-- lib
  |    +-- lua
  |         +-- 5.2
  +-- man
  |    +-- man1
  +-- share
       +-- lua
            +-- 5.2

But checking the default paths; (added some linebreaks for readability)
C:\Temp\lua\5.2>bin\lua
Lua 5.2.1  Copyright (C) 1994-2012 Lua.org, PUC-Rio
> print("PATH: "..package.path .. "\n\nCPATH: " .. package.cpath)
PATH:
C:\Temp\lua\5.2\bin\lua\?.lua;
C:\Temp\lua\5.2\bin\lua\?\init.lua;
C:\Temp\lua\5.2\bin\?.lua;
C:\Temp\lua\5.2\bin\?\init.lua;
.\?.lua

CPATH:
C:\Temp\lua\5.2\bin\?.dll;
C:\Temp\lua\5.2\bin\loadall.dll;
.\?.dll
>

So any files placed in the generated ./lib/lua/5.2/ or ./share/lua/5.2/ paths will not be found. So the make file is inconsistent with the default paths.

Shouldn't the default paths be updated to include those locations, and make it consistent?

Thijs


Reply | Threaded
Open this post in threaded view
|

Re: Makefile vs LUA_PATH inconsistency

Andrew Starks



On Thu, May 15, 2014 at 1:47 PM, Thijs Schreijer <[hidden email]> wrote:
When building Lua using MinGW, the following structure is produced;

{root}
  +-- bin
  +-- include
  +-- lib
  |    +-- lua
  |         +-- 5.2
  +-- man
  |    +-- man1
  +-- share
       +-- lua
            +-- 5.2

But checking the default paths; (added some linebreaks for readability)
C:\Temp\lua\5.2>bin\lua
Lua 5.2.1  Copyright (C) 1994-2012 Lua.org, PUC-Rio
> print("PATH: "..package.path .. "\n\nCPATH: " .. package.cpath)
PATH:
C:\Temp\lua\5.2\bin\lua\?.lua;
C:\Temp\lua\5.2\bin\lua\?\init.lua;
C:\Temp\lua\5.2\bin\?.lua;
C:\Temp\lua\5.2\bin\?\init.lua;
.\?.lua

CPATH:
C:\Temp\lua\5.2\bin\?.dll;
C:\Temp\lua\5.2\bin\loadall.dll;
.\?.dll
>

So any files placed in the generated ./lib/lua/5.2/ or ./share/lua/5.2/ paths will not be found. So the make file is inconsistent with the default paths.

Shouldn't the default paths be updated to include those locations, and make it consistent?

Thijs


Do you think that path should be different (like use (_WIN32 && !(_MINGW) ) ) or should the make file build an alternate structure?

If Lua is typically put in a sandbox, then I'd change the Makefile. If it's typically put inside part of the MinGW sandbox, then changing the luaconf.h would make more sense.

Either way, it should be consistent. It would be nice if you didn't having to set environment variables for default installations and that should be an attainable goal.

-Andrew

Reply | Threaded
Open this post in threaded view
|

Re: Makefile vs LUA_PATH inconsistency

Dirk Laurie-2
In reply to this post by Thijs Schreijer
2014-05-15 20:47 GMT+02:00 Thijs Schreijer <[hidden email]>:

> When building Lua using MinGW, the following structure is produced;
>
> {root}
>   +-- bin
>   +-- include
>   +-- lib
>   |    +-- lua
>   |         +-- 5.2
>   +-- man
>   |    +-- man1
>   +-- share
>        +-- lua
>             +-- 5.2
>
> But checking the default paths; (added some linebreaks for readability)
> C:\Temp\lua\5.2>bin\lua
> Lua 5.2.1  Copyright (C) 1994-2012 Lua.org, PUC-Rio
>> print("PATH: "..package.path .. "\n\nCPATH: " .. package.cpath)
> PATH:
> C:\Temp\lua\5.2\bin\lua\?.lua;
> C:\Temp\lua\5.2\bin\lua\?\init.lua;
> C:\Temp\lua\5.2\bin\?.lua;
> C:\Temp\lua\5.2\bin\?\init.lua;
> .\?.lua
>
> CPATH:
> C:\Temp\lua\5.2\bin\?.dll;
> C:\Temp\lua\5.2\bin\loadall.dll;
> .\?.dll
>>
>
> So any files placed in the generated ./lib/lua/5.2/ or ./share/lua/5.2/ paths will not be found. So the make file is inconsistent with the default paths.
>
> Shouldn't the default paths be updated to include those locations, and make it consistent?

It has nothing to do with the Makefile. As the manual states,
default paths are in luaconf.h. The relevant lines are:

#if defined(_WIN32)     /* { */
/*
** In Windows, any exclamation mark ('!') in the path is replaced by the
** path of the directory of the executable file of the current process.
*/
#define LUA_LDIR        "!\\lua\\"
#define LUA_CDIR        "!\\"
#define LUA_PATH_DEFAULT  \
                LUA_LDIR"?.lua;"  LUA_LDIR"?\\init.lua;" \
                LUA_CDIR"?.lua;"  LUA_CDIR"?\\init.lua;" ".\\?.lua"
#define LUA_CPATH_DEFAULT \
                LUA_CDIR"?.dll;" LUA_CDIR"loadall.dll;" ".\\?.dll"

Not being a Windows user, I have no idea why it is done this
way, but others that do have that exquisite privilege may know.

Reply | Threaded
Open this post in threaded view
|

RE: Makefile vs LUA_PATH inconsistency

Thijs Schreijer


> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Dirk Laurie
> Sent: vrijdag 16 mei 2014 7:46
> To: Lua mailing list
> Subject: Re: Makefile vs LUA_PATH inconsistency
>
> 2014-05-15 20:47 GMT+02:00 Thijs Schreijer <[hidden email]>:
> > When building Lua using MinGW, the following structure is produced;
> >
> > {root}
> >   +-- bin
> >   +-- include
> >   +-- lib
> >   |    +-- lua
> >   |         +-- 5.2
> >   +-- man
> >   |    +-- man1
> >   +-- share
> >        +-- lua
> >             +-- 5.2
> >
> > But checking the default paths; (added some linebreaks for readability)
> > C:\Temp\lua\5.2>bin\lua
> > Lua 5.2.1  Copyright (C) 1994-2012 Lua.org, PUC-Rio
> >> print("PATH: "..package.path .. "\n\nCPATH: " .. package.cpath)
> > PATH:
> > C:\Temp\lua\5.2\bin\lua\?.lua;
> > C:\Temp\lua\5.2\bin\lua\?\init.lua;
> > C:\Temp\lua\5.2\bin\?.lua;
> > C:\Temp\lua\5.2\bin\?\init.lua;
> > .\?.lua
> >
> > CPATH:
> > C:\Temp\lua\5.2\bin\?.dll;
> > C:\Temp\lua\5.2\bin\loadall.dll;
> > .\?.dll
> >>
> >
> > So any files placed in the generated ./lib/lua/5.2/ or ./share/lua/5.2/
> paths will not be found. So the make file is inconsistent with the default
> paths.
> >
> > Shouldn't the default paths be updated to include those locations, and
> make it consistent?
>
> It has nothing to do with the Makefile. As the manual states,
> default paths are in luaconf.h. The relevant lines are:
>
> #if defined(_WIN32)     /* { */
> /*
> ** In Windows, any exclamation mark ('!') in the path is replaced by the
> ** path of the directory of the executable file of the current process.
> */
> #define LUA_LDIR        "!\\lua\\"
> #define LUA_CDIR        "!\\"
> #define LUA_PATH_DEFAULT  \
>                 LUA_LDIR"?.lua;"  LUA_LDIR"?\\init.lua;" \
>                 LUA_CDIR"?.lua;"  LUA_CDIR"?\\init.lua;" ".\\?.lua"
> #define LUA_CPATH_DEFAULT \
>                 LUA_CDIR"?.dll;" LUA_CDIR"loadall.dll;" ".\\?.dll"
>
> Not being a Windows user, I have no idea why it is done this
> way, but others that do have that exquisite privilege may know.

I'm aware of this. But it’s the inconsistency between luaconf.h and the makefile (default behaviors) that I intended to address.

Thijs

Reply | Threaded
Open this post in threaded view
|

Re: Makefile vs LUA_PATH inconsistency

Ulrich Schmidt
In reply to this post by Dirk Laurie-2


Am 16.05.2014 07:46, schrieb Dirk Laurie:

> 2014-05-15 20:47 GMT+02:00 Thijs Schreijer <[hidden email]>:
>> When building Lua using MinGW, the following structure is produced;
>>
>> {root}
>>    +-- bin
>>    +-- include
>>    +-- lib
>>    |    +-- lua
>>    |         +-- 5.2
>>    +-- man
>>    |    +-- man1
>>    +-- share
>>         +-- lua
>>              +-- 5.2
>>

There is no global accepted rule where to install lua.
I compiled/installed luajit on ARM-Linux and your directory tree becomes
created in /usr/local/. Thats ok for me. Luadist makefiles does not
recognize the installed juajit and do not cooperate with it. So it does
not matter where you pull your module sources: you need to modify the
makefiles anyway. After playing with Lua for a year on windows & Linux,
i know there is no widely accepted way to name installed files and no
widely accepted rule where to store the installed files.

So if you want to set up your own running lua environment: "Roll your
Own!" Thats state of the art. And as long each developer / each distro
keeps creating own rules it will keep being this way.

Ulrich.

Reply | Threaded
Open this post in threaded view
|

RE: Makefile vs LUA_PATH inconsistency

Thijs Schreijer
In reply to this post by Andrew Starks


> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Andrew Starks
> Sent: donderdag 15 mei 2014 22:56
> To: Lua mailing list
> Subject: Re: Makefile vs LUA_PATH inconsistency
>
>
>
> On Thu, May 15, 2014 at 1:47 PM, Thijs Schreijer <[hidden email]>
> wrote:
> When building Lua using MinGW, the following structure is produced;
>
> {root}
>   +-- bin
>   +-- include
>   +-- lib
>   |    +-- lua
>   |         +-- 5.2
>   +-- man
>   |    +-- man1
>   +-- share
>        +-- lua
>             +-- 5.2
>
> But checking the default paths; (added some linebreaks for readability)
> C:\Temp\lua\5.2>bin\lua
> Lua 5.2.1  Copyright (C) 1994-2012 Lua.org, PUC-Rio
> > print("PATH: "..package.path .. "\n\nCPATH: " .. package.cpath)
> PATH:
> C:\Temp\lua\5.2\bin\lua\?.lua;
> C:\Temp\lua\5.2\bin\lua\?\init.lua;
> C:\Temp\lua\5.2\bin\?.lua;
> C:\Temp\lua\5.2\bin\?\init.lua;
> .\?.lua
>
> CPATH:
> C:\Temp\lua\5.2\bin\?.dll;
> C:\Temp\lua\5.2\bin\loadall.dll;
> .\?.dll
> >
>
> So any files placed in the generated ./lib/lua/5.2/ or ./share/lua/5.2/
> paths will not be found. So the make file is inconsistent with the default
> paths.
>
> Shouldn't the default paths be updated to include those locations, and make
> it consistent?
>
> Thijs
>
> Do you think that path should be different (like use (_WIN32 && !(_MINGW) )
> ) or should the make file build an alternate structure?
>
> If Lua is typically put in a sandbox, then I'd change the Makefile. If it's
> typically put inside part of the MinGW sandbox, then changing the luaconf.h
> would make more sense.
>
> Either way, it should be consistent. It would be nice if you didn't having
> to set environment variables for default installations and that should be an
> attainable goal.
>
> -Andrew

Changing the paths has a drawback that it would have to include `\\..\\share\\lua\\5.2\\`. The issue is '..' here, as it moves up, so with a binary placed top-level (not in .\bin\), it would traverse out of the application structure on the file system and start exploring unknown paths there. That's what makes me uncomfortable with changing the paths. Otoh any one deviating from defaults is on his own, and should know what he's doing.

Alternatively updating the file structure generated by the makefile could be a solution. But then there is MinGW; is it Windows, or Unix? I think the paths defined for Windows are ok. But how much can/should Windows deviate from the other platforms?


A Windows like structure (working with the current default paths in luaconf.h) would be;

 {root}
   +-- 5.2           <-- contains '/bin' contents and binary modules (.dll)
        +-- include  <-- no changes
        +-- lib      <-- no changes
        +-- lua      <-- Lua modules

Binary modules would also go in the '5.2' directory, no longer in 'lib'.

If you want to keep the versioning in the tree itself, instead of the toplevel version number, then the /bin and /lib contents must also become versioned, which it currently isn't. (eg. makefile produces lua.exe, which should become lua52.exe) That would also imply that the paths would also need updating to include the versions (so paths & makefile changes)

Thijs


Reply | Threaded
Open this post in threaded view
|

Re: Makefile vs LUA_PATH inconsistency

Dirk Laurie-2
In reply to this post by Thijs Schreijer
2014-05-16 9:19 GMT+02:00 Thijs Schreijer <[hidden email]>:

>
>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]] On
>> Behalf Of Dirk Laurie
>> Sent: vrijdag 16 mei 2014 7:46
>> To: Lua mailing list
>> Subject: Re: Makefile vs LUA_PATH inconsistency
>>
>> 2014-05-15 20:47 GMT+02:00 Thijs Schreijer <[hidden email]>:
>> > When building Lua using MinGW, the following structure is produced;
>> >
>> > {root}
>> >   +-- bin
>> >   +-- include
>> >   +-- lib
>> >   |    +-- lua
>> >   |         +-- 5.2
>> >   +-- man
>> >   |    +-- man1
>> >   +-- share
>> >        +-- lua
>> >             +-- 5.2
>> >
>> > But checking the default paths; (added some linebreaks for readability)
>> > C:\Temp\lua\5.2>bin\lua
>> > Lua 5.2.1  Copyright (C) 1994-2012 Lua.org, PUC-Rio
>> >> print("PATH: "..package.path .. "\n\nCPATH: " .. package.cpath)
>> > PATH:
>> > C:\Temp\lua\5.2\bin\lua\?.lua;
>> > C:\Temp\lua\5.2\bin\lua\?\init.lua;
>> > C:\Temp\lua\5.2\bin\?.lua;
>> > C:\Temp\lua\5.2\bin\?\init.lua;
>> > .\?.lua
>> >
>> > CPATH:
>> > C:\Temp\lua\5.2\bin\?.dll;
>> > C:\Temp\lua\5.2\bin\loadall.dll;
>> > .\?.dll
>> >>
>> >
>> > So any files placed in the generated ./lib/lua/5.2/ or ./share/lua/5.2/
>> paths will not be found. So the make file is inconsistent with the default
>> paths.
>> >
>> > Shouldn't the default paths be updated to include those locations, and
>> make it consistent?
>>
>> It has nothing to do with the Makefile. As the manual states,
>> default paths are in luaconf.h. The relevant lines are:
>>
>> #if defined(_WIN32)     /* { */
>> /*
>> ** In Windows, any exclamation mark ('!') in the path is replaced by the
>> ** path of the directory of the executable file of the current process.
>> */
>> #define LUA_LDIR        "!\\lua\\"
>> #define LUA_CDIR        "!\\"
>> #define LUA_PATH_DEFAULT  \
>>                 LUA_LDIR"?.lua;"  LUA_LDIR"?\\init.lua;" \
>>                 LUA_CDIR"?.lua;"  LUA_CDIR"?\\init.lua;" ".\\?.lua"
>> #define LUA_CPATH_DEFAULT \
>>                 LUA_CDIR"?.dll;" LUA_CDIR"loadall.dll;" ".\\?.dll"
>>
>> Not being a Windows user, I have no idea why it is done this
>> way, but others that do have that exquisite privilege may know.
>
> I'm aware of this. But it’s the inconsistency between luaconf.h and the makefile (default behaviors) that I intended to address.

The Makefile that comes with Lua, as downloaded from lua.org, has
Linux defaults.

$ make echo | grep MOD
INSTALL_LMOD= /usr/local/share/lua/5.2
INSTALL_CMOD= /usr/local/lib/lua/5.2

What does yours look like? If different, who changed it?

Reply | Threaded
Open this post in threaded view
|

RE: Makefile vs LUA_PATH inconsistency

Thijs Schreijer
In reply to this post by Ulrich Schmidt

>
> There is no global accepted rule where to install lua.
> I compiled/installed luajit on ARM-Linux and your directory tree becomes
> created in /usr/local/. Thats ok for me. Luadist makefiles does not
> recognize the installed juajit and do not cooperate with it. So it does
> not matter where you pull your module sources: you need to modify the
> makefiles anyway. After playing with Lua for a year on windows & Linux,
> i know there is no widely accepted way to name installed files and no
> widely accepted rule where to store the installed files.
>
> So if you want to set up your own running lua environment: "Roll your
> Own!" Thats state of the art. And as long each developer / each distro
> keeps creating own rules it will keep being this way.
>
> Ulrich.

But at least the defaults should work out-of-the-box, no?

Thijs
Reply | Threaded
Open this post in threaded view
|

Re: Makefile vs LUA_PATH inconsistency

Ulrich Schmidt


Am 16.05.2014 10:52, schrieb Thijs Schreijer:

>
>>
>> There is no global accepted rule where to install lua.
>> I compiled/installed luajit on ARM-Linux and your directory tree becomes
>> created in /usr/local/. Thats ok for me. Luadist makefiles does not
>> recognize the installed juajit and do not cooperate with it. So it does
>> not matter where you pull your module sources: you need to modify the
>> makefiles anyway. After playing with Lua for a year on windows & Linux,
>> i know there is no widely accepted way to name installed files and no
>> widely accepted rule where to store the installed files.
>>
>> So if you want to set up your own running lua environment: "Roll your
>> Own!" Thats state of the art. And as long each developer / each distro
>> keeps creating own rules it will keep being this way.
>>
>> Ulrich.
>
> But at least the defaults should work out-of-the-box, no?
>
> Thijs
>

If i want to be rude, i would say: "there are no defaults i can trust."
Everyone defines his private setup as "default". So we have as many
"defaults" as we have Lua versions, modules, distibutions and so on.
(not counting my own default ;) ).

And no one thought about, windows need a complete different directory- &
file name structure. In case you want to install Lua5.2 and (Lua5.1 ||
Luajit) parallel on Windows, the Linux directory tree does not fit the
windows needs.

But all this is no big issue: Define your own directory structure,
adjust PATH & CPATH, cannibalize existing makefiles and "Roll your own" ^^

Ulrich.

Reply | Threaded
Open this post in threaded view
|

Re: Makefile vs LUA_PATH inconsistency

Andrew Starks


On Friday, May 16, 2014, Ulrich Schmidt <[hidden email]> wrote:


Am 16.05.2014 10:52, schrieb Thijs Schreijer:


There is no global accepted rule where to install lua.
I compiled/installed luajit on ARM-Linux and your directory tree becomes
created in /usr/local/. Thats ok for me. Luadist makefiles does not
recognize the installed juajit and do not cooperate with it. So it does
not matter where you pull your module sources: you need to modify the
makefiles anyway. After playing with Lua for a year on windows & Linux,
i know there is no widely accepted way to name installed files and no
widely accepted rule where to store the installed files.

So if you want to set up your own running lua environment: "Roll your
Own!" Thats state of the art. And as long each developer / each distro
keeps creating own rules it will keep being this way.

Ulrich.

But at least the defaults should work out-of-the-box, no?

Thijs


If i want to be rude, i would say: "there are no defaults i can trust."
Everyone defines his private setup as "default". So we have as many "defaults" as we have Lua versions, modules, distibutions and so on. (not counting my own default ;) ).

And no one thought about, windows need a complete different directory- & file name structure. In case you want to install Lua5.2 and (Lua5.1 || Luajit) parallel on Windows, the Linux directory tree does not fit the windows needs.

But all this is no big issue: Define your own directory structure, adjust PATH & CPATH, cannibalize existing makefiles and "Roll your own" ^^

Ulrich.


Ulrich,

Why have the default at all if the default is broken out of the box?

What we all do is not hyper-relevant. I believe that this affects...

...what someone who installs Lua for the first time experiences
...what LuaRocks should follow, by default.


I don't use MinGW. Does it have the "usr/local" structure? If you install something like git, is it expected to be nested into /usr/local/bin, or similar? If so, then I believe that the luaconf.h file should root itself there, if it were possible. 

If not, then the make file would need to use the Windows structure. 

I do not think that the tree needs to be versioned, given that it's rooted to a specific executable. That is, unless my other suggestion were to be adopted (make specific version first search, then non-version second search). 


Reply | Threaded
Open this post in threaded view
|

Re: Makefile vs LUA_PATH inconsistency

Dirk Laurie-2
2014-05-16 15:04 GMT+02:00 Andrew Starks <[hidden email]>:
> On Friday, May 16, 2014, Ulrich Schmidt <[hidden email]> wrote:
>> Am 16.05.2014 10:52, schrieb Thijs Schreijer:
>>> But at least the defaults should work out-of-the-box, no?
>> Everyone defines his private setup as "default".
> Why have the default at all if the default is broken out of the box?

It's not broken out of the box except on Windows. So what's new?

Reply | Threaded
Open this post in threaded view
|

Re: Makefile vs LUA_PATH inconsistency

Peter Drahoš
On Fri, May 16, 2014 at 4:55 PM, Dirk Laurie <[hidden email]> wrote:
> 2014-05-16 15:04 GMT+02:00 Andrew Starks <[hidden email]>:
>> On Friday, May 16, 2014, Ulrich Schmidt <[hidden email]> wrote:
>>> Am 16.05.2014 10:52, schrieb Thijs Schreijer:
>>>> But at least the defaults should work out-of-the-box, no?
>>> Everyone defines his private setup as "default".
>> Why have the default at all if the default is broken out of the box?
>
> It's not broken out of the box except on Windows. So what's new?
>
Windows has one nice feature in PATH/CPATH handling. You can use
relative paths from the executable location using the exclamation mark
"!". Eg. LUA_CPATH="!/../lib/lua/?.dll". This is especially helpful
for self contained installations, standalone Lua applications etc.
LuaDist[1] extends this functionality to other OSes so it does not
need to install into the system and can be moved around as needed.
Additionally you can set your own defaults in the CMake based build we
provide[2].

pd

[1] https://github.com/LuaDist/lua/blob/master/src/loadlib_rel.c#L144
[2] https://github.com/LuaDist/lua/blob/master/CMakeLists.txt#L36

Reply | Threaded
Open this post in threaded view
|

Re: Makefile vs LUA_PATH inconsistency

Andrew Starks
In reply to this post by Dirk Laurie-2

On Fri, May 16, 2014 at 9:55 AM, Dirk Laurie <[hidden email]> wrote:

It's not broken out of the box except on Windows. So what's new?

I didn't see a smiley face, so I assume that this is an honest question...

In Windows, the question of where to put script files, dlls and command line executables is not so much a matter of debate (Microsoft provides answers to these questions) as it is foreign enough that it's not typical for packages like Lua to adopt / provide installation procedures that follow those conventions. This seems reasonable, to me.

The trouble is when *some* help is provided and when that help is in contradiction with other settings. This is what happens with the MinGW option.

As Peter Drahoš points out, because `!\` means "the path of the host executable", we can avoid the debate entirely and the user can decide where to install "lua.exe" without needing any further configuration. Specifically, they don't need to set LUA_PATH or LUA_CPATH and at most, they add `lua.exe` to their path.

So yes, it's broken (or at least misleading and messy) for MinGW, but it seems like it could be so easily cleaned up. For MSVS, the situation is fine, except that LuaRocks still wants to use the *nix sub-tree structure, but that's another issue...

--Andrew


Reply | Threaded
Open this post in threaded view
|

Re: Makefile vs LUA_PATH inconsistency

David Heiko Kolf-2
In reply to this post by Thijs Schreijer
Thijs Schreijer wrote:

> When building Lua using MinGW, the following structure is produced;
>
> {root}
>   +-- bin
>   +-- include
>   +-- lib
>   |    +-- lua
>   |         +-- 5.2
>   +-- man
>   |    +-- man1
>   +-- share
>        +-- lua
>             +-- 5.2

Did you run "make install"? I just skimmed through the Makefile and it
looks to me like "make install" wouldn't make a lot of sense on Windows.

When I am building Lua on Windows I just run "make mingw" and that
usually works out of the box for me -- all the libraries are looked for
relative to the host application (which I copy manually instead of using
"make install").

"make mingw" to me just means to use MinGW to build the generally usable
Windows DLL and EXE, not to build a configuration specially tailored to
MSYS where those paths might be relevant.

Best regards,

David Kolf


Reply | Threaded
Open this post in threaded view
|

RE: Makefile vs LUA_PATH inconsistency

Thijs Schreijer


> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of David Heiko Kolf
> Sent: vrijdag 16 mei 2014 18:06
> To: Lua mailing list
> Subject: Re: Makefile vs LUA_PATH inconsistency
>
> Thijs Schreijer wrote:
> > When building Lua using MinGW, the following structure is produced;
> >
> > {root}
> >   +-- bin
> >   +-- include
> >   +-- lib
> >   |    +-- lua
> >   |         +-- 5.2
> >   +-- man
> >   |    +-- man1
> >   +-- share
> >        +-- lua
> >             +-- 5.2
>
> Did you run "make install"? I just skimmed through the Makefile and it
> looks to me like "make install" wouldn't make a lot of sense on Windows.

Windows perfectly handles this structure, no problem. It's just that the defaults for the paths do not work.
Adding to the defaults LUA_PATH="!/../share/lua/5.2/?.lua;!/../share/lua/5.2/?/init.lua" (similar to Peters remarks) would simply align the paths with the makefile.

It's easy to fix (when you know what you're doing), but it doesn't work out of the box. And as Andrew mentioned; what good are defaults if they don't work?

>
> When I am building Lua on Windows I just run "make mingw" and that
> usually works out of the box for me -- all the libraries are looked for
> relative to the host application (which I copy manually instead of using
> "make install").
>
> "make mingw" to me just means to use MinGW to build the generally usable
> Windows DLL and EXE, not to build a configuration specially tailored to
> MSYS where those paths might be relevant.

All too easy when you know what you're doing. But remembering my own Lua start, I picked up Lua for Windows tried some compilers and LuaRocks, but couldn't for the life of me get it to work. Just because of all these little nitty gritty details I had to set manually. I dropped it for 2 years then came back and finally got it going.

I don't see why it should be so hard for newbies, if also the defaults could be fixed to just work.

Thijs

PS. Besides the above, the Windows + VS build is still the only platform where Lua by default is build _without_ the COMPATALL option (in 'luavs.bat'), which is also pretty useless as a default. Would be nice to fix that too...



Reply | Threaded
Open this post in threaded view
|

Re: Makefile vs LUA_PATH inconsistency

Luiz Henrique de Figueiredo
In reply to this post by Thijs Schreijer
> But it's the inconsistency between luaconf.h and the makefile (default behaviors) that I intended to address.

What exactly do you propose to change in the top-level Makefile?
Changing INSTALL_LMOD and INSTALL_CMOD dos not really work because the
paths in luaconf.h include the location of lua.exe, which is not known
at build time and changes dynamically at each invocation.

Reply | Threaded
Open this post in threaded view
|

Re: Makefile vs LUA_PATH inconsistency

Ulrich Schmidt


Am 20.05.2014 01:56, schrieb Luiz Henrique de Figueiredo:
>> But it's the inconsistency between luaconf.h and the makefile (default behaviors) that I intended to address.
>
> What exactly do you propose to change in the top-level Makefile?
> Changing INSTALL_LMOD and INSTALL_CMOD dos not really work because the
> paths in luaconf.h include the location of lua.exe, which is not known
> at build time and changes dynamically at each invocation.
>
We need to distinguish between windows- and linux installation 1st.
- windows is probably easier to do. lua.exe knows where installed ("!"
in path strings) and we can put modules, tests and docs in subfolders,
for instance:

lua.exe +- modules/ +- 5.1/  (standard modules .dll & .lua)
         |           +- 5.2/
         +- share/ + ...         (doc, tests, ...)
         |
         +- lua/ +- 5.1/       (user modules )
         |       +- 5.2/
         ...

Linux is different caused by the fact that lua* becomes installed at
different locations, usually /usr/bin/ or /usr/local/bin/.
so we have different installation roots. (if you want to take a "make
dist" in account, there is a 3rd installation root: Output/ )
the installation- & PATH- tree may look like:

LUA_ROOT +- /bin/ +- lua-5.1*
          |        +- luac-5.1*
          |        +- luajit*
          |        +- lua-5.2*
          |        +- lua* => lua-5.2*
          |
          +- /lib/ +- liblua-5.1.so
          +- /lib/ +- liblua-5.2.so
          |        +- lua/ +- 5.1/
          |                +- 5.2/
          +- share/ + ...

So the makefile need to know the target is Win/Linux and it needs to
know the LUA_ROOT.

A widely accepted subfolder tree should become a official proposal. it
should allow a peaceful coexistence of lua versions and luajit & lua5.1
=> luajit replacement.

Ulrich.

Reply | Threaded
Open this post in threaded view
|

RE: Makefile vs LUA_PATH inconsistency

Thijs Schreijer
In reply to this post by Luiz Henrique de Figueiredo

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Luiz Henrique de Figueiredo
> Sent: dinsdag 20 mei 2014 1:57
> To: Lua mailing list
> Subject: Re: Makefile vs LUA_PATH inconsistency
>
> > But it's the inconsistency between luaconf.h and the makefile (default
> behaviors) that I intended to address.
>
> What exactly do you propose to change in the top-level Makefile?
> Changing INSTALL_LMOD and INSTALL_CMOD dos not really work because the
> paths in luaconf.h include the location of lua.exe, which is not known
> at build time and changes dynamically at each invocation.

I'm for keeping the platform differences minimal. So in this case the structure produced by `make install` (though not very windowish) will work fine. I would rather update the default paths in `luaconf.h`.

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

Change it to this;
LUA_PATH
  !\\lua\\?.lua;
  !\\lua\\?\\init.lua;
  !\\?.lua;
  !\\?\\init.lua;
  !\\..\\share\\lua\\5.2\\?.lua;       --> added
  !\\..\\share\\lua\\5.2\\?\\init.lua  --> added
  .\\?.lua"

LUA_CPATH
  !\\?.dll;
  !\\..\\lib\\lua\\5.2\\?.dll          --> added
  !\\loadall.dll;
  .\\?.dll

Then it includes the locations as produced by the makefile.

What does need to be updated in the toplevel makefile are these lines;

  # What to install.
  TO_BIN= lua luac

To:

  # What to install.
  ifeq ($(OS),Windows_NT)
  TO_BIN= lua luac lua$(subst .,,$V).dll
  else
  TO_BIN= lua luac
  endif

Because by default the .dll file is missing from an installation. Currently one must manually add `TO_BIN="lua.exe luac.exe lua52.dll"` to the `make install` command.

Thijs

Reply | Threaded
Open this post in threaded view
|

RE: Makefile vs LUA_PATH inconsistency

Thijs Schreijer
In reply to this post by Ulrich Schmidt


> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Ulrich Schmidt
> Sent: dinsdag 20 mei 2014 8:24
> To: [hidden email]
> Subject: Re: Makefile vs LUA_PATH inconsistency
>
>
>
> Am 20.05.2014 01:56, schrieb Luiz Henrique de Figueiredo:
> >> But it's the inconsistency between luaconf.h and the makefile (default
> behaviors) that I intended to address.
> >
> > What exactly do you propose to change in the top-level Makefile?
> > Changing INSTALL_LMOD and INSTALL_CMOD dos not really work because the
> > paths in luaconf.h include the location of lua.exe, which is not known
> > at build time and changes dynamically at each invocation.
> >
> We need to distinguish between windows- and linux installation 1st.

How is MinGW classified? Is it windows or unix or both?

> - windows is probably easier to do. lua.exe knows where installed ("!"
> in path strings) and we can put modules, tests and docs in subfolders,
> for instance:
>
> lua.exe +- modules/ +- 5.1/  (standard modules .dll & .lua)
>          |           +- 5.2/
>          +- share/ + ...         (doc, tests, ...)
>          |
>          +- lua/ +- 5.1/       (user modules )
>          |       +- 5.2/
>          ...
>
> Linux is different caused by the fact that lua* becomes installed at
> different locations, usually /usr/bin/ or /usr/local/bin/.
> so we have different installation roots. (if you want to take a "make
> dist" in account, there is a 3rd installation root: Output/ )
> the installation- & PATH- tree may look like:
>
> LUA_ROOT +- /bin/ +- lua-5.1*
>           |        +- luac-5.1*
>           |        +- luajit*
>           |        +- lua-5.2*
>           |        +- lua* => lua-5.2*
>           |
>           +- /lib/ +- liblua-5.1.so
>           +- /lib/ +- liblua-5.2.so
>           |        +- lua/ +- 5.1/
>           |                +- 5.2/
>           +- share/ + ...
>
> So the makefile need to know the target is Win/Linux and it needs to
> know the LUA_ROOT.
>
> A widely accepted subfolder tree should become a official proposal. it
> should allow a peaceful coexistence of lua versions and luajit & lua5.1
> => luajit replacement.

Can't we use the currently created structure as the "widely accepted subfolder tree"? There is no technical reason that it won't work. It's just not very windowish, and it limits platform differences.

>
> Ulrich.


Reply | Threaded
Open this post in threaded view
|

Re: Makefile vs LUA_PATH inconsistency

steve donovan
In reply to this post by Thijs Schreijer
On Tue, May 20, 2014 at 9:49 AM, Thijs Schreijer
<[hidden email]> wrote:
> I'm for keeping the platform differences minimal. So in this case the structure produced by `make install` (though not very windowish) will work fine. I would rather update the default paths in `luaconf.h`.

OK, so this makes the package (c)path versioned, but surely we get
versioning from the fact that each separate Lua executable gets its
own subtree based on its location?

1234