 |
lua-l archive |
|
|
||
|
On 7 Sep 2015 22:02, "Sean Conner" <sean@conman.org> wrote:
>
> It was thus said that the Great Stefano once stated:
> > On 7 September 2015 at 03:39, Sean Conner <sean@conman.org> wrote:
> > > Thanks for the work, but I'm having difficulty understanding the output
> > > from all this. For instance, I only found one of my modules [1] in the
> > > Windows output [2] and while I would like to fix the issue, I don't [3]
> > > use Windows, so I'm at a loss as to how to fix this issue:
> > >
> > > env.c
> > > env.c(44): warning C4273: '__p__environ': inconsistent dll linkage
> > > C:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt\stdlib.h(1158): note: see previous definition of '__p__environ'
> > > Microsoft (R) Incremental Linker Version 14.00.23026.0
> > > Copyright (C) Microsoft Corporation. All rights reserved.
> > >
> > > Creating library org/conman/env.lib and object org/conman/env.exp
> > > Installing https://luarocks.org/org.conman.env-1.0.1-0.rockspec...
> > > Using https://luarocks.org/org.conman.env-1.0.1-0.rockspec... switching to 'build' mode
> > > cl /nologo /MD /O2 -c -Foenv.obj -IC:/ste/luarocks/2.2/include env.c
> > > link -dll -def:env.def -out:org/conman/env.dll C:/ste/luarocks/2.2/lua51.lib env.obj
> > > Updating manifest for C:/ste/luarockstree/lib/luarocks/rocks
> > > org.conman.env 1.0.1-0 is now built and installed in C:/ste/luarockstree (license: LGPL)
> >
> > That is just a warning, it builds fine (see below).
> > If you are concerned please send me privately a test and I can run on
> > my Windows VM.
>
> It may build fine, but does it *run*?
Good question.
That is where a standardised way to invoke tests would help.
One of the points I complained about in my original post when talking about the lack of policy.
> This modules just populates a Lua
> table with all the environment variables in the process. Under Unix, you
> can get an array of all the environment variables two ways---one as an
> additional parameter to main()
>
> int main(int argc,char *argv[],char *envp[])
>
> and the second way is through an external variable:
>
> extern char **environ;
>
> I read the error above (and I'm guessing, since I don't use Windows, nor
> do I know the programming environment) that I *might* not get the extern
> environ variable at run time, or if I do, I might not get the one I'm
> expecting.
>
> > > Another issue: I'm checking the pass list [4] and I see this for two of
> > > my modules:
> > >
> > > ["org.conman.env"] = {
> > > ["1.0.1-2"] = {
> > > Linux = {
> > > x86 = true
> > > },
> > > OSX = {
> > > x86 = true
> > > },
> > > Windows = {
> > > x86 = true
> > > }
> > > }
> > > },
> > > ["org.conman.errno"] = {
> > > ["1.0.1-2"] = {
> > > Linux = {
> > > x86 = false
> > > },
> > > OSX = {
> > > x86 = false
> > > },
> > > Windows = {
> > > x86 = false
> > > }
> > > }
> > > },
> > >
> > > Um ... did org.conman.errno pass? Why is the Linux.x86 set to false? I
> > > *know* it compiled under Linux x86 as that's my main development system. I
> > > know it also compiles under 64-bit Linux as I use that at work. I also know
> > > it compiled under OS-X as I use that both at home and at work. What am I
> > > looking at?
> >
> > Nope.
> > The rock org.conman.env passed on all 3 platforms.
> > The rock org.conman.errno did not pass on any.
>
> <nitpick>Then why is org.conman.errno included in the "pass"
> list?</nitpick>
The pass.lua file answers the question: does it build and satisfy all criteria (no module name conflict for instance)?
true: yes
false: no
nil: not attempted (excluded as rock list it as unsupported os)
>
> > The reason is found immediately looking at
> > http://www.scilua.org/luarocksorg/state/error.lua
>
> <nitpick>It may be obvious to you, but it wasn't to me.</nitpick>
That was the first point in the task list of what to check when a module did not pass.
I am preparing a better reporting view (auto generated webpage) for everyone's convenience.
>
> > There is a module conflict (org module name).
> > I am aware in this case it's a module intentionally splitted among
> > multiple rocks and I am going to support this case shortly. So nothing
> > for you to worry about.
> > (side note: I am not convinced on the need to break-up modules in
> > multiple rocks, considering their tiny size, but I can live with
> > that).
>
> Ah. Your mistake here is assuming that "org.conman.errno" is a submodule
> of "org". That is not the case here. Each of my modules are (with one
> exception) independent of each other and all can be used by themselves.
> What I *am* doing is namespacing my modules. There are several Lua modules
I am not assuming anything really. I just know that multiple rocks try to write in the same org directory and that this is not allowed for now (by me).
The exact relationship is not important, they might even just contain documentation and it would not make a difference.
What will happen is that there will be a single org package packing together all your rocks.
> that wrap syslog(). There are several Lua modules that wrap sockets. There
> are several Lua modules that wrap POSIX filesystem calls. There are several
> Lua modules that wrap the signal() function. Instead of creating some
> oddball bame like "spcsignal" or "conmansyslog" I opted instead to pull them
> all under a common namespace, based off my primary DNS domain name. [1]
>
> > > I've got too many questions to even start looking into my luarock modules.
> > > And while I can fix the Linux and OS-X issues, I have no Windows systems [3]
> > > nor do I understand that platform to fix issues there. And I'm sure there
> > > are people who can fix Windows issues but not OS-X or Linux.
> >
> > Philipp already replied to the lua.h issue (thanks!), I answered the
> > reaming questions.
> > The best I can do is to provide you with the full stderr and stout
> > outputs from Luarocks: this is what you would get if you were to try
> > to install the rock yourself on a Windows machine. I am not sure how I
> > can improve on this short of giving you ssh access to a Windows VM.
> >
> > Please let me know if I can help further.
>
> It wouldn't help in my case. I don't do development under Windows; I
> don't know the development environment so even if I had access, I wouldn't
> know how to fix the issue.
Sure, in the next release there will be support for OS-specific packages.
If you do not plan on supporting Windows please consider to add supported os info in the rockspec.
Stefano
>
> -spc
>
> [1] There are some that don't like my choice of namespace, but I feel
> it's better than nothing.
>