Re: To all Lua rock maintainers (also included considerations on Lua's ecosystem and a Lua distribution)

[Sean Conner <sean@...>]

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*?  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 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>

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

  -spc

[1]	There are some that don't like my choice of namespace, but I feel
	it's better than nothing.