I just used TCL instead of Lua - here is why

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

I just used TCL instead of Lua - here is why

Pierre Chapuis
I just wanted to share this with the list in case others feel the same way.

I usually write code that runs on unices, but in my current position I happen to regularly write small pieces of code which run in customers' environments, typically as scheduled tasks.

The other day I had such a simple task: connect to a proprietary database using ODBC and extract some data as CSV.

Initially I tried to use Lua for it. I fell into a rabbit hole. I could find no decent documentation about the best way to achieve this: get a Lua interpreter that can speak ODBC on Windows, and run my script with it. I couldn't find a binary module for lua-odbc or LuaSQL-ODBC, or a distribution that includes one of them. I couldn't find decent documentation about how to start from scratch on Windows and achieve this (including installing a compiler if needed, luarocks, etc, or how to easily build a module to work with LuaBinaries [1] for instance).


That was a task for work so eventually I had to do the reasonable thing and give up. I googled TCL + ODBC and noticed it was in their standard library. I downloaded freeWrap [2], wrote a quick script and called "freewrapTCLSH.exe my_script.tcl". I obtained an executable I just had to drop on the customer's machine.


This makes me a little sad because Lua would be perfect for this task. This is not about ODBC being in the TCL standard library. Even if it wasn't they have a way to do the same almost as easily with third party modules [3].

It is just about it being too hard to just run some code with a C dependency on Windows (without something like msys2). On Linux or Mac it is reasonably easy but on Windows we really lack either a distribution with an extensive collection of binary modules (for instance a 3rd party repository relying on LuaBinaries), or a simple way to build standalone executables with C deps from scratch (for instance a distribution of MinGW + Lua + LuaRocks).

Does anyone here have the same problem, a solution (I might just not know the Lua on Windows ecosystem well enough) or a project that aims to solve this?

[1] http://luabinaries.sourceforge.net
[2] http://freewrap.sourceforge.net
[3] http://tclexecomp.sourceforge.net/documentation/customize/

--
Pierre Chapuis
Reply | Threaded
Open this post in threaded view
|

Re: I just used TCL instead of Lua - here is why

Marc Balmer
First hit on Google:



Am 11.01.2021 um 12:42 schrieb Pierre Chapuis <[hidden email]>:

I just wanted to share this with the list in case others feel the same way.

I usually write code that runs on unices, but in my current position I happen to regularly write small pieces of code which run in customers' environments, typically as scheduled tasks.

The other day I had such a simple task: connect to a proprietary database using ODBC and extract some data as CSV.

Initially I tried to use Lua for it. I fell into a rabbit hole. I could find no decent documentation about the best way to achieve this: get a Lua interpreter that can speak ODBC on Windows, and run my script with it. I couldn't find a binary module for lua-odbc or LuaSQL-ODBC, or a distribution that includes one of them. I couldn't find decent documentation about how to start from scratch on Windows and achieve this (including installing a compiler if needed, luarocks, etc, or how to easily build a module to work with LuaBinaries [1] for instance).


That was a task for work so eventually I had to do the reasonable thing and give up. I googled TCL + ODBC and noticed it was in their standard library. I downloaded freeWrap [2], wrote a quick script and called "freewrapTCLSH.exe my_script.tcl". I obtained an executable I just had to drop on the customer's machine.


This makes me a little sad because Lua would be perfect for this task. This is not about ODBC being in the TCL standard library. Even if it wasn't they have a way to do the same almost as easily with third party modules [3].

It is just about it being too hard to just run some code with a C dependency on Windows (without something like msys2). On Linux or Mac it is reasonably easy but on Windows we really lack either a distribution with an extensive collection of binary modules (for instance a 3rd party repository relying on LuaBinaries), or a simple way to build standalone executables with C deps from scratch (for instance a distribution of MinGW + Lua + LuaRocks).

Does anyone here have the same problem, a solution (I might just not know the Lua on Windows ecosystem well enough) or a project that aims to solve this?

[1] http://luabinaries.sourceforge.net
[2] http://freewrap.sourceforge.net
[3] http://tclexecomp.sourceforge.net/documentation/customize/

--
Pierre Chapuis

Reply | Threaded
Open this post in threaded view
|

Re: I just used TCL instead of Lua - here is why

pocomane
In reply to this post by Pierre Chapuis
On Mon, Jan 11, 2021 at 12:44 PM Pierre Chapuis wrote:
> on Windows we really lack either a distribution with an extensive collection of binary modules (for instance a 3rd party repository relying on LuaBinaries), or a simple way to build standalone executables with C deps from scratch (for instance a distribution of MinGW + Lua + LuaRocks).

I agree that lua on Windows is a bit problematic. For the "Build all
by yourself" path, I used cross-compilation and a simple script [1]
which, among other things, is responsible for downloading the full gcc
toolchain [2]. It statically compiles lua plus some modules (lfs,
luasocket, etc). I do not know how complex it would be to add the
lua-odbc module.

Moreover:
- An utility is provided to embed the script in the executable.
- Releases binaries (win, mac, linux and arm) are automatically built
with Travis-CI.

Mimmo Mane.

[1] https://github.com/pocomane/lua_static_battery
[2] a static musl-based one, taken from https://musl.cc
Reply | Threaded
Open this post in threaded view
|

Re: I just used TCL instead of Lua - here is why

Kaj Eijlers
In reply to this post by Pierre Chapuis
I wish I had a solution, I definitely had a similar experience.

About 2 weeks ago I needed a version of luafilesystem that was for a different lua version than the one I always use on Windows, and spent about 4 hours trying to get LuaRocks working and compiling it for me. It was not a great experience and I ended up googling for an OpenSource project that used it and came with a Visual Studio solution. And I've been programming on video game consoles for 3 decades, am one of those people that still works in a DOS window 90% of the time, so I am not unfamiliar with having to figure something out, but there was just too many issues that needed resolving with very confusing leads. Permissions? Paths? I don't know, I gave up.

I totally believe it's a smooth experience on *nix but my Windows experience was truthfully infuriating.

Kaj


Reply | Threaded
Open this post in threaded view
|

Re: I just used TCL instead of Lua - here is why

Viacheslav Usov
In reply to this post by Pierre Chapuis
On Mon, Jan 11, 2021 at 12:44 PM Pierre Chapuis <[hidden email]> wrote:

> a simple way to build standalone executables with C deps from scratch (for instance a distribution of MinGW + Lua + LuaRocks).

The Vcpkg project serves me well: https://github.com/microsoft/vcpkg.
I can vouch for the LuaSQL library specifically in the ODBC case that
it covers (albeit patched for some particular bad driver).

This needs a relatively recent Visual Studio. A Community Edition can
be used for free under certain conditions.

Cheers,
V.
Reply | Threaded
Open this post in threaded view
|

Re: I just used TCL instead of Lua - here is why

Pierre Chapuis
Thank you all for your answers.

I really like the approach of cross-compiling from Linux using a static toolchain based on musl. I think I will look into it when I have time.

I will probably also try the vcpkg route with Visual Studio although I'd like to avoid using it of possible.

--
Pierre Chapuis
Reply | Threaded
Open this post in threaded view
|

Re: I just used TCL instead of Lua - here is why

Ką Mykolas
Would You also please consider MSYS2 infrastructure? I do have a few
friends who are particulary happy about it.
Also, lately I was thinking to dig deeper into MingW providing some
builds which may scratch my and someone else's itches...

Another elephant in the room, which, in my blunt opinion should not be
forgotten, Windows is a bitch to develop for and maintain.
Packaging and installers are pretty hard to do, and to do it well.
Plenty of foundations and companies who does FOSS are forced
either to invest some additional money or just to ditch it entirely
for the community to sort it (Win packaging/bundling/etc) out on their
own.

For example, if I recall it right, from a few latest conferences, for
QGis it takes like... ~5% of revenue just to pay someone to deal with
it.

On Tue, Jan 12, 2021 at 10:55 AM Pierre Chapuis <[hidden email]> wrote:
>
> Thank you all for your answers.
>
> I really like the approach of cross-compiling from Linux using a static toolchain based on musl. I think I will look into it when I have time.
>
> I will probably also try the vcpkg route with Visual Studio although I'd like to avoid using it of possible.
>
> --
> Pierre Chapuis
Reply | Threaded
Open this post in threaded view
|

Re: I just used TCL instead of Lua - here is why

Russell Haley
In reply to this post by Pierre Chapuis
http://winlua.net

That's precisely why I created WinLua, it contains Lua, LuaRocks and the LLVM-Mingw compiler. The LLD linker has a gotcha (doesn't link to DLLs, only static or *.lib files), and I am currently working on the debugger machine interface. However, Lua, LuaRocks and the compiler all work well together. I have included GNU make as well as xmake (lua based build system) and  regularly use it. Give it a spin and let me know what you think!

Russ

On Mon, Jan 11, 2021 at 3:44 AM Pierre Chapuis <[hidden email]> wrote:
I just wanted to share this with the list in case others feel the same way.

I usually write code that runs on unices, but in my current position I happen to regularly write small pieces of code which run in customers' environments, typically as scheduled tasks.

The other day I had such a simple task: connect to a proprietary database using ODBC and extract some data as CSV.

Initially I tried to use Lua for it. I fell into a rabbit hole. I could find no decent documentation about the best way to achieve this: get a Lua interpreter that can speak ODBC on Windows, and run my script with it. I couldn't find a binary module for lua-odbc or LuaSQL-ODBC, or a distribution that includes one of them. I couldn't find decent documentation about how to start from scratch on Windows and achieve this (including installing a compiler if needed, luarocks, etc, or how to easily build a module to work with LuaBinaries [1] for instance).


That was a task for work so eventually I had to do the reasonable thing and give up. I googled TCL + ODBC and noticed it was in their standard library. I downloaded freeWrap [2], wrote a quick script and called "freewrapTCLSH.exe my_script.tcl". I obtained an executable I just had to drop on the customer's machine.


This makes me a little sad because Lua would be perfect for this task. This is not about ODBC being in the TCL standard library. Even if it wasn't they have a way to do the same almost as easily with third party modules [3].

It is just about it being too hard to just run some code with a C dependency on Windows (without something like msys2). On Linux or Mac it is reasonably easy but on Windows we really lack either a distribution with an extensive collection of binary modules (for instance a 3rd party repository relying on LuaBinaries), or a simple way to build standalone executables with C deps from scratch (for instance a distribution of MinGW + Lua + LuaRocks).

Does anyone here have the same problem, a solution (I might just not know the Lua on Windows ecosystem well enough) or a project that aims to solve this?

[1] http://luabinaries.sourceforge.net
[2] http://freewrap.sourceforge.net
[3] http://tclexecomp.sourceforge.net/documentation/customize/

--
Pierre Chapuis
Reply | Threaded
Open this post in threaded view
|

Re: I just used TCL instead of Lua - here is why

Andrew Starks-2
In reply to this post by Pierre Chapuis


> On Jan 11, 2021, at 05:44, Pierre Chapuis <[hidden email]> wrote:
>
> Does anyone here have the same problem, a solution (I might just not know the Lua on Windows ecosystem well enough) or a project that aims to solve this?

I didn’t want the first part of your question, asked many times in different ways, to get lost in the helpful answers to the second part of your question.

Thankfully, there was a solution, as has been pointed out. I’ve used lua-odbc successfully in the distant past. But your core experience is the norm. When trying to use Lua as a scripting language, especially on windows, it’s often a PITA. Often not because the solution doesn’t exist, but because, for whatever reason, it’s not accessible.

The same is true for developers new to Lua, looking to embed it, that are either curious, or are told by their tyrannical  product manager that it’s a hard requirement. They know python, or just about any other language out there, and are shocked by the lack of much bigger standard library and what feels like an uneven ecosystem.

There are many that love the language from past experiences or can appreciate its simplicity and excellent design and so they do the work to find the excellent libraries and projects that are out there.

I have repeated this many times and I apologize for that, but I’m sad that many never get past the obstacles experienced by the OP and thus miss out on those discoveries.  Lua is such a beautiful piece of engineering and design and I think it’s a shame that many miss out because of this issue.

-Andrew
Tyrannical Product Manager  
Reply | Threaded
Open this post in threaded view
|

Re: I just used TCL instead of Lua - here is why

Pierre Chapuis
In reply to this post by Russell Haley
On Tue, Jan 12, 2021, at 16:26, Russell Haley wrote:

That's precisely why I created WinLua, it contains Lua, LuaRocks and the LLVM-Mingw compiler. The LLD linker has a gotcha (doesn't link to DLLs, only static or *.lib files), and I am currently working on the debugger machine interface. However, Lua, LuaRocks and the compiler all work well together. I have included GNU make as well as xmake (lua based build system) and  regularly use it. Give it a spin and let me know what you think!

I installed it and installed odbc with LuaRocks, it worked.

I tried to install LuaSocket but it failed. Apparently it is due to to an incompatibility between LuaSocket and MinGW-GCC. See https://gist.github.com/catwell/44bc95ca61c2c5529dedb162f22e47b6

Do you have an example project using xmake with it?

-- 
Pierre Chapuis
Reply | Threaded
Open this post in threaded view
|

Re: I just used TCL instead of Lua - here is why

Marcus Mason
In reply to this post by Pierre Chapuis
I have always chosen to build it manually for msvc. Building and linking a stock lua implementation is really not too bad with msvc's tools. Luarocks can be configured to use this toolchain too. I had more success using 3rd party libraries with msvc compilers than mingw personally.

On Mon, Jan 11, 2021 at 11:44 AM Pierre Chapuis <[hidden email]> wrote:
I just wanted to share this with the list in case others feel the same way.

I usually write code that runs on unices, but in my current position I happen to regularly write small pieces of code which run in customers' environments, typically as scheduled tasks.

The other day I had such a simple task: connect to a proprietary database using ODBC and extract some data as CSV.

Initially I tried to use Lua for it. I fell into a rabbit hole. I could find no decent documentation about the best way to achieve this: get a Lua interpreter that can speak ODBC on Windows, and run my script with it. I couldn't find a binary module for lua-odbc or LuaSQL-ODBC, or a distribution that includes one of them. I couldn't find decent documentation about how to start from scratch on Windows and achieve this (including installing a compiler if needed, luarocks, etc, or how to easily build a module to work with LuaBinaries [1] for instance).


That was a task for work so eventually I had to do the reasonable thing and give up. I googled TCL + ODBC and noticed it was in their standard library. I downloaded freeWrap [2], wrote a quick script and called "freewrapTCLSH.exe my_script.tcl". I obtained an executable I just had to drop on the customer's machine.


This makes me a little sad because Lua would be perfect for this task. This is not about ODBC being in the TCL standard library. Even if it wasn't they have a way to do the same almost as easily with third party modules [3].

It is just about it being too hard to just run some code with a C dependency on Windows (without something like msys2). On Linux or Mac it is reasonably easy but on Windows we really lack either a distribution with an extensive collection of binary modules (for instance a 3rd party repository relying on LuaBinaries), or a simple way to build standalone executables with C deps from scratch (for instance a distribution of MinGW + Lua + LuaRocks).

Does anyone here have the same problem, a solution (I might just not know the Lua on Windows ecosystem well enough) or a project that aims to solve this?

[1] http://luabinaries.sourceforge.net
[2] http://freewrap.sourceforge.net
[3] http://tclexecomp.sourceforge.net/documentation/customize/

--
Pierre Chapuis
Reply | Threaded
Open this post in threaded view
|

Re: I just used TCL instead of Lua - here is why

Sudipto Mallick
No one mentioned the Tiny C Compiler[1][2]. You can download it from
here[3] then the latest source code from here[2] and bootstrap it. See
win32/tcc-win32.txt in the source distribution for help.
Then you can download tcc-busybox-for-win32.zip and build the patched
busybox and gmake therein with tcc. This gives you a system and
environment capable of building lua and other sources and also very
lightweight, much much less than hundreds of megabytes.

[1]        https://tinycc.org/
[2]        https://repo.or.cz/tinycc.git
           Click .tar.gz or .zip link from the 'mob' branch.
[3]        http://download.savannah.nongnu.org/releases/tinycc/
           Download the appropriate tcc-0.9.27-win{32,64}-bin.zip
depending on your system being 32-bit or 64-bit
Reply | Threaded
Open this post in threaded view
|

Re: I just used TCL instead of Lua - here is why

Victor Bombi
In reply to this post by Pierre Chapuis

Hi,

I dont know what is xmake and I dont use Luarocks but I made a subfolder to my Lua2SC project in order to compile LuaSocket with cmake and mingw-w64: https://github.com/sonoro1234/Lua2SC/tree/master/luasocket_cmake

On January 13, 2021 at 3:23 PM Pierre Chapuis <[hidden email]> wrote:

On Tue, Jan 12, 2021, at 16:26, Russell Haley wrote:

That's precisely why I created WinLua, it contains Lua, LuaRocks and the LLVM-Mingw compiler. The LLD linker has a gotcha (doesn't link to DLLs, only static or *.lib files), and I am currently working on the debugger machine interface. However, Lua, LuaRocks and the compiler all work well together. I have included GNU make as well as xmake (lua based build system) and  regularly use it. Give it a spin and let me know what you think!

I installed it and installed odbc with LuaRocks, it worked.

I tried to install LuaSocket but it failed. Apparently it is due to to an incompatibility between LuaSocket and MinGW-GCC. See  https://gist.github.com/catwell/44bc95ca61c2c5529dedb162f22e47b6

Do you have an example project using xmake with it?

-- 
Pierre Chapuis


 

Reply | Threaded
Open this post in threaded view
|

Re: I just used TCL instead of Lua - here is why

Russell Haley
In reply to this post by Pierre Chapuis


On Wed, Jan 13, 2021 at 6:25 AM Pierre Chapuis <[hidden email]> wrote:
On Tue, Jan 12, 2021, at 16:26, Russell Haley wrote:

That's precisely why I created WinLua, it contains Lua, LuaRocks and the LLVM-Mingw compiler. The LLD linker has a gotcha (doesn't link to DLLs, only static or *.lib files), and I am currently working on the debugger machine interface. However, Lua, LuaRocks and the compiler all work well together. I have included GNU make as well as xmake (lua based build system) and  regularly use it. Give it a spin and let me know what you think!

I installed it and installed odbc with LuaRocks, it worked.
*I KNOW RIGHT?* It was like an epiphany the first time it worked right out of the box.

I tried to install LuaSocket but it failed. Apparently it is due to to an incompatibility between LuaSocket and MinGW-GCC. See https://gist.github.com/catwell/44bc95ca61c2c5529dedb162f22e47b6
Sadly my joy was also short lived. It's easy to patch if you clone the luasocket git repository. Comment out line 37 in rockspec/luasocket-3.0rc2-1.rockspec 
 Here a the diff:
PS C:\Users\russh\git\luasocket> git diff
diff --git a/rockspec/luasocket-3.0rc2-1.rockspec b/rockspec/luasocket-3.0rc2-1.rockspec
index dfe5275..257eef4 100644
--- a/rockspec/luasocket-3.0rc2-1.rockspec
+++ b/rockspec/luasocket-3.0rc2-1.rockspec
@@ -34,7 +34,7 @@ local function make_plat(plat)
     },
     mingw32 = {
       "LUASOCKET_DEBUG",
-      "LUASOCKET_INET_PTON",
+--      "LUASOCKET_INET_PTON",
       "WINVER=0x0501"
     }
   }

The problem is caused by different levels of Windows API support. The GNU installation supports Windows XP, the mingw library I am using does not.  I haven't had time to drill in and find a proper solution.

Do you have an example project using xmake with it?

First: I apologize, I am unprepared. I just recently tore down my development environment and mangled another one while testing installers and whatnot.

Please run the following command from powershell or CMD: 
xmake global --mingw= 'C:\Program Files (x86)\WinLua\WLC\'

That will set up xmake to work globally with WinLua's mingw installation (I am trying to automate that step through the installer, hence my broken environments). If you have existing C/C++ code, you can navigate into your source directory and type `xmake f -p mingw -a x86_64`. Xmake will try to find your source code and create a project (-a i686 or -a i386 will also work for 32 bit; they are synonyms for each other). A couple of weeks back I auto generated zlib and it worked really well. The xmake.lua file that is generated has comment notes at the bottom that will give you pointers on how to write xmake and where to find documentation. https://xmake.io/#/

As for example projects, I have a bunch of junk scattered around, let me see what I can find. I have a two part article about Sol 3 C++ Lua bindings and I introduce xmake: 

Here is the contents of the xmake file from the article:

set_languages("c++17")
-- define target
target("main")

    -- set kind
    set_kind("binary")

    -- add files
    add_files("main.cpp", "appConfig.cpp")

    add_includedirs("include", "C:\\Program Files (x86)\\WinLua\\Lua\\5.3\\include")

    add_linkdirs("C:\\Program Files (x86)\\WinLua\\Lua\\5.3\\bin")
    add_links("lua53")

    after_build(function(target)
        os.cp("proj1.lua", path.join(target:targetdir(),"proj1.lua"))
    end);

That should get you started?

Xmake is quite easy if you've used SCONS or CMake. I think it's one of the most brilliant pieces of development software I've used. I'm excited about my own project, but xmake is so much cooler and bigger than WinLua. 


-- 
Pierre Chapuis
Reply | Threaded
Open this post in threaded view
|

Re: I just used TCL instead of Lua - here is why

Russell Haley
In reply to this post by Sudipto Mallick


On Wed, Jan 13, 2021 at 8:34 AM Sudipto Mallick <[hidden email]> wrote:
No one mentioned the Tiny C Compiler[1][2]. You can download it from
here[3] then the latest source code from here[2] and bootstrap it. See
win32/tcc-win32.txt in the source distribution for help.
Then you can download tcc-busybox-for-win32.zip and build the patched
busybox and gmake therein with tcc. This gives you a system and
environment capable of building lua and other sources and also very
lightweight, much much less than hundreds of megabytes.

[1]        https://tinycc.org/
[2]        https://repo.or.cz/tinycc.git
           Click .tar.gz or .zip link from the 'mob' branch.
[3]        http://download.savannah.nongnu.org/releases/tinycc/
           Download the appropriate tcc-0.9.27-win{32,64}-bin.zip
depending on your system being 32-bit or 64-bit
Ha! That's so cool.  What does it use for a standard C Library?  What size does your full environment come in at?

I've been able to get WinLua down to about 230 Mb without sacrificing any of the core functionality,  but nothing like Tiny CC.  I might be able to shrink it further by compiling with dynamic libraries, but that makes the compiler slower and it's already slow because of Windows. LLVM-Mingw is smoking fast on Linux or FreeBSD. (I think GCC 9 recently took the speed crown back from CLang?)

In terms of size:
Visual Studio: 20,000 - 40,000 Mb
Visual Studio Build Tools (MSBuild, VC, tools): 6,00 Mb
WinLua: 600 Mb

Reply | Threaded
Open this post in threaded view
|

Re: I just used TCL instead of Lua - here is why

Russell Haley
In reply to this post by Russell Haley


On Wed, Jan 13, 2021 at 7:03 PM Russell Haley <[hidden email]> wrote:


On Wed, Jan 13, 2021 at 6:25 AM Pierre Chapuis <[hidden email]> wrote:
On Tue, Jan 12, 2021, at 16:26, Russell Haley wrote:

That's precisely why I created WinLua, it contains Lua, LuaRocks and the LLVM-Mingw compiler. The LLD linker has a gotcha (doesn't link to DLLs, only static or *.lib files), and I am currently working on the debugger machine interface. However, Lua, LuaRocks and the compiler all work well together. I have included GNU make as well as xmake (lua based build system) and  regularly use it. Give it a spin and let me know what you think!

I installed it and installed odbc with LuaRocks, it worked.
*I KNOW RIGHT?* It was like an epiphany the first time it worked right out of the box.

I tried to install LuaSocket but it failed. Apparently it is due to to an incompatibility between LuaSocket and MinGW-GCC. See https://gist.github.com/catwell/44bc95ca61c2c5529dedb162f22e47b6
Sadly my joy was also short lived. It's easy to patch if you clone the luasocket git repository. Comment out line 37 in rockspec/luasocket-3.0rc2-1.rockspec 
 Here a the diff:
PS C:\Users\russh\git\luasocket> git diff
diff --git a/rockspec/luasocket-3.0rc2-1.rockspec b/rockspec/luasocket-3.0rc2-1.rockspec
index dfe5275..257eef4 100644
--- a/rockspec/luasocket-3.0rc2-1.rockspec
+++ b/rockspec/luasocket-3.0rc2-1.rockspec
@@ -34,7 +34,7 @@ local function make_plat(plat)
     },
     mingw32 = {
       "LUASOCKET_DEBUG",
-      "LUASOCKET_INET_PTON",
+--      "LUASOCKET_INET_PTON",
       "WINVER=0x0501"
     }
   }
Sorry, I missed a detail (um, the build command!). To build luasocket navigate to the git repo, patch it and then run: luarocks make .\rockspec\luasocket-3.0rc2-1.rockspec


The problem is caused by different levels of Windows API support. The GNU installation supports Windows XP, the mingw library I am using does not.  I haven't had time to drill in and find a proper solution.

Do you have an example project using xmake with it?

First: I apologize, I am unprepared. I just recently tore down my development environment and mangled another one while testing installers and whatnot.

Please run the following command from powershell or CMD: 
xmake global --mingw= 'C:\Program Files (x86)\WinLua\WLC\'

That will set up xmake to work globally with WinLua's mingw installation (I am trying to automate that step through the installer, hence my broken environments). If you have existing C/C++ code, you can navigate into your source directory and type `xmake f -p mingw -a x86_64`. Xmake will try to find your source code and create a project (-a i686 or -a i386 will also work for 32 bit; they are synonyms for each other). A couple of weeks back I auto generated zlib and it worked really well. The xmake.lua file that is generated has comment notes at the bottom that will give you pointers on how to write xmake and where to find documentation. https://xmake.io/#/

As for example projects, I have a bunch of junk scattered around, let me see what I can find. I have a two part article about Sol 3 C++ Lua bindings and I introduce xmake: 

Here is the contents of the xmake file from the article:

set_languages("c++17")
-- define target
target("main")

    -- set kind
    set_kind("binary")

    -- add files
    add_files("main.cpp", "appConfig.cpp")

    add_includedirs("include", "C:\\Program Files (x86)\\WinLua\\Lua\\5.3\\include")

    add_linkdirs("C:\\Program Files (x86)\\WinLua\\Lua\\5.3\\bin")
    add_links("lua53")

    after_build(function(target)
        os.cp("proj1.lua", path.join(target:targetdir(),"proj1.lua"))
    end);

That should get you started?

Xmake is quite easy if you've used SCONS or CMake. I think it's one of the most brilliant pieces of development software I've used. I'm excited about my own project, but xmake is so much cooler and bigger than WinLua. 


-- 
Pierre Chapuis
Reply | Threaded
Open this post in threaded view
|

Re: I just used TCL instead of Lua - here is why

Sudipto Mallick
In reply to this post by Russell Haley
> Ha! That's so cool.
> What does it use for a standard C Library?
Obviously msvcrt.dll
>  What size does your full environment come in at?
The actual compiler is approx. 500 KB + header files (winapi/ takes
approx. 1MB), bounds checking and backtrace support (without gdb,
these are godsend): approx. 1.5 MB + busybox+gmake: approx. 1MB = in
total a little over 3MB
This is on Win7 32-bit.

> I've been able to get WinLua down to about 230 Mb without sacrificing any
> of the core functionality,  but nothing like Tiny CC.  I might be able to
> shrink it further by compiling with dynamic libraries, but that makes the
> compiler slower and it's already slow because of Windows.
If tcc was named fast c compiler, no one can object. A really great
experience is to see the tcc compiling itself in a few seconds... But
the problem is the generated code is not that efficient. TCC does some
simple optimizations but not like GCC or Clang. That's the tradeoff.


--Sudipto Mallick