lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]




On 4 Jan 2018, at 07:20, Russell Haley <russ.haley@gmail.com> wrote:

On Tue, Jan 2, 2018 at 10:27 AM, Thijs Schreijer
<thijs@thijsschreijer.nl> wrote:
Not sure, but if KH Man is right, then make sure that you:

1. build Lua, and
2. install LuaRocks, and
3. install the rock

All with the same toolchain.
My last two attempts were built with Lua compiled in VS 2017 on the
same computer moments earlier. Perhaps this is a question for a
Microsoft forum.

It’s hard to tell. Without more info. What does your LuaRocks config file look like? Typing just `luarocks` on the command line should give you the location of the config file.


I'll try again later in my MSYS2 environment and compare. I question
if the DLLs have been built correctly.


MSYS won’t work, that’s a unix/posix environment. The gcc toolchain can work, but might require some manual fiddling with the config file. A PR was just merged to make this more “automagic” for gcc based distributions. There are some instruction [1] using MinGW (which is the older 32 bit unmaintained version, the newer 64bit maintained MinGW is supported by the recent PR)

A random shot in the dark: are there Windows binaries available via
LuaRocks packages (and can they be filtered for)? Is there stomach for
such things?

I can see the appeal of something like LuaForWindows and also how it
could get quite unwieldy. I was considering going down that road with
a Windows installer. My preference would be to include LuaRocks in the
installer. If simple things like LuaFileSystem can't be grabbed easily
then that presents other challenges. My next consideration is to build
some simple components and include them [1]. The final thought is to
create some Win64 binaries of the tools I like and publish the rocks.

[1] Or build them right into Lua? That breaks APIs though. I
understand the reason lfs isn't built into the language, but perhaps
it could be included with the sources and an optional target created?
Perhaps a tools directory? Just a thought.

As Steve commented, it’s the changing runtimes that are a major pita for this. But even then a bunch of Luarocks packages for windows only build with either gcc or MS toolchains (using make files etc, instead of the LuaRocks build backbend), so some packages will still be unavailable depending on your compiler choice.

Since the binary distributions are labelled as “win32” with LuaRocks, there is no notion of the runtime libs they have been build with. So for now impossible to build a reliable set of binary rocks, simply because we cannot label them properly.


Russ

Anyway, you could also give LuaWinMulti [2] a try, it’s a batch file that installs multiple Lua versions with accompanying LuaRocks versions. But you might run into the same issue as I have never tested it with VS 2017.

I’d be interested in the results though.

Thijs

[1] Lua on Windows: http://www.thijsschreijer.nl/blog/?p=863 but most of the steps are automated by [2]
[2] LuaWinMulti https://github.com/Tieske/luawinmulti