_samt_

> I don’t see your comment about LuaSocket. Is it in a different thread?

Yes it's in another thread.

clx provides a simpler, stackless C++ API because it doesn't use the Lua VM.

The Lua C API compatibility layer lets you reuse existing binary modules without rewriting their source code. The wrapper is there for compatibility, not because modules must be written that way.

For new modules, you can use clx's native C++ API directly.

Windows can statically link libraries just fine. That's not the point :)

When your application depends on several Lua and binary modules, you may have to compile each binary module, embed the Lua scripts while preserving their expected module paths, link everything against the Lua VM, and write glue/loading code to make everything work together (see the comment below regarding LuaSocket)

Of course, it's possible. But it's a lot of manual work, especially for newcomers.

With clx, the goal is simple: compile your Lua program into a native executable. No stock Lua VM dependency, no glue code, no module-loading code to write.

Lua was designed primarily as an embeddable scripting language, and embedding the interpreter as a library is absolutely a valid way to use it :)

My point is about deploying standalone applications.

Tools like srlua, luastatic, and many others, package Lua scripts with the interpreter and required libraries. These bundled executables can sometimes trigger antivirus false positives, just like tools such as py2exe for Python. They use packaging techniques that can resemble those used by malware, which is why I called this approach "hacky".

Sure, but it becomes a pain when you have several dependencies. Take LuaSocket, for example: it has binary modules, Lua scripts, and folder-related requirements to deal with.

Static linking itself is not a problem for Lua.

If all you want is a tiny script that checks the weather or downloads a file, having to manually link or bundle all those pieces just to ship a standalone executable is a lot of work. That's one of the problems clx aims to solve.

It will be hacky if you need binary modules. Some platforms (Windows I see you !) don't permit to link binary modules to a static executable. Your only possibility is to embed the Lua dynamic library and the binary modules your need, extract them somewhere and so on...

The primary goal of clx is not size or performance but to ship standalone executables without the need of the Lua VM with a native approach rather than the well known (and somewhat hacky) way to embed a script and the LuaVM inside an executable (and when using binary modules it can be quite tricky !)

Agreed, native compilation alone doesn't guarantee better performance. clx has its own optimizer and runtime, and the results depend on the workload. It doesn't beat LuaJIT on everything and that's not it's primary goal.

As for AI, I've spent months of my free time building clx. The design and implementation are mine. It's true that I use AI to help with documentation and to debug complex issues, but that doesn't make the project AI-generated.

Totally agree, and that's why clx static analysis and optimizer steps permits some performance gains

Thanks for pointing that out, it might be diffu ule to read on some résolutions

A technical write‑up about the difficulties of compiling Lua to native code, based on my experience developing clx

Good catch, thanks.

The release archive currently extracts directly into the working directory. I'll package future releases into a dedicated top-level directory to avoid cluttering the extraction location.

Yes that's it