Feature Request: LuaWinMake in Next Release?

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

Feature Request: LuaWinMake in Next Release?

Russell Haley
Good News Everyone!

I took a few minutes today at work with a fresh Windows 10 VM to test LuaWinMake with the Visual Studio C++ Build Tools and can report success. All I had to do was open the "Visual Studio Developer Console", move the winmake.bat file into my Lua directory and type winmake.bat. 


That means Lua can be built from standard Windows tools, with or without the Visual Studio IDE. The Build Tools includes the VC compiler and toolchain (1.75 GB) and the Windows 10 SDK (~2.6 GB). The only thin missing is a compatible build recipe with the lua source code.

To further my quest to improve Lua on Windows, I'll ask if it's possible for the Lua Team to include the LuaWinMake batch file with the source code in the next release? I understand that a Linux based team may not have the resources to maintain two or three VS Solution files, but hopefully including a single batch file could be considered? 

To further my point, I'd say most people interested in programming on Windows will have some form of Visual Studio on their computer. That single batch file can open up Lua to a lot of developers that are turned away by the requirements for a GNU toolchain. 

I was once a Windows only developer and I had to chase my tail trying to get into Lua. It was *infuriating* realizing that I couldn't build Lua when every other tool I had ever needed to compile worked just fine with VS. My initial response was "No official binary download and no way to build without learning GNU tools. F-that." I was fortunate that I had a friend that helped me through that and showed me how to get running.  

The VC Build Tools download proves that there is a viable way to build and run Lua and LuaRocks without needing Visual Studio or GNU tools. It makes me bonkers to think that this little batch file could have saved me years of work (at night) and I might not have needed to start WinLua. I could have gone to a console, typed winmake.bat, installed LuaRocks, and moved on with Lua. 

For all of us that enjoy using Lua on Windows (and all of those that are currently unable to build Lua on Windows), I hope you consider my request.  

Thanks again for the great language.  :)

Russ
Reply | Threaded
Open this post in threaded view
|

Re: Feature Request: LuaWinMake in Next Release?

Gisle Vanem
Russell Haley wrote:

> I took a few minutes today at work with a fresh Windows 10 VM to test LuaWinMake with the Visual Studio C++ Build Tools
> and can report success. All I had to do was open the "Visual Studio Developer Console", move the winmake.bat file into
> my Lua directory and type winmake.bat.
>
> https://github.com/Tieske/luawinmake

Nice, I tried it. But it does not with a TCC/4NT-shell
(it doesn't like the awful cmd construct in LFCHAR).

That aside, how can it build a 32-bit LUA with a dual-mode
MinGW (tdm-gcc or MinGW64-w64). With those, when winmake.bat does
a 'gcc', it implies 64-bit ('gcc -m64'). How can I specify
'gcc -m32'?

There should perhaps be a way to 'set EXTRAFLAG=-m32' from the
cmd-line.

--
--gv

Reply | Threaded
Open this post in threaded view
|

Re: Feature Request: LuaWinMake in Next Release?

Thijs Schreijer


> On 30 May 2018, at 11:40, Gisle Vanem <[hidden email]> wrote:
>
> Russell Haley wrote:
>
>> I took a few minutes today at work with a fresh Windows 10 VM to test LuaWinMake with the Visual Studio C++ Build Tools and can report success. All I had to do was open the "Visual Studio Developer Console", move the winmake.bat file into my Lua directory and type winmake.bat.
>> https://github.com/Tieske/luawinmake
>
> Nice, I tried it. But it does not with a TCC/4NT-shell
> (it doesn't like the awful cmd construct in LFCHAR).

Well, that is a commercial command-shell replacement… if it doesn’t work maybe raise an issue with them regarding compatibility?
And yes it is one of the ugliest hack I’ve ever done, and that says a lot [1]. Unfortunately Windows batch files are still the most “compatible” way of doing stuff like this without extra dependencies. But it does require occasional hacks due to its limitations.

>
> That aside, how can it build a 32-bit LUA with a dual-mode
> MinGW (tdm-gcc or MinGW64-w64). With those, when winmake.bat does
> a 'gcc', it implies 64-bit ('gcc -m64'). How can I specify
> 'gcc -m32'?
>
> There should perhaps be a way to 'set EXTRAFLAG=-m32' from the
> cmd-line.

The aim of luawinmake is to just build Lua. It auto-detects the Lua version from the source code. It works for Lua 5.1, 5.2 and 5.3 (5.4 is available as a separate branch). And it works with all common compilers available for Windows (also auto-detected).

So a PR would be most welcome :)

>
> --
> --gv
>


[1] unfortunately about more of my code than just luawinmake :)
Reply | Threaded
Open this post in threaded view
|

Re: Feature Request: LuaWinMake in Next Release?

Thijs Schreijer
In reply to this post by Russell Haley

On 30 May 2018, at 06:33, Russell Haley <[hidden email]> wrote:

Good News Everyone!

I took a few minutes today at work with a fresh Windows 10 VM to test LuaWinMake with the Visual Studio C++ Build Tools and can report success. All I had to do was open the "Visual Studio Developer Console", move the winmake.bat file into my Lua directory and type winmake.bat. 

Thx for the praise, that is exactly what it was meant to do :)



That means Lua can be built from standard Windows tools, with or without the Visual Studio IDE. The Build Tools includes the VC compiler and toolchain (1.75 GB) and the Windows 10 SDK (~2.6 GB). The only thin missing is a compatible build recipe with the lua source code.

To further my quest to improve Lua on Windows, I'll ask if it's possible for the Lua Team to include the LuaWinMake batch file with the source code in the next release? I understand that a Linux based team may not have the resources to maintain two or three VS Solution files, but hopefully including a single batch file could be considered? 

Maybe a mention in the “windows” chapter on the website or source documentation can go a long way in helping Windows users out?