如何在一个 .exe 文件中构建并链接 Lua 核心和几个 Lua 模块
我需要制作可在 Windows、Linux、MacOS 上运行且无需安装的便携式应用程序。它必须是一个可执行文件，并且不能有其他库文件（.dll、.so ...）。我将使用 ANSI C 并为每个平台重新编译项目。我想使用Lua脚本，所以必须在我的代码中嵌入Lua解释器。我需要网络和其他一些模块来编写，但我现在 Lua 已经有用于此目的的模块，所以我将使用它们而不是编写我自己的模块。 我怎样才能将所有这些，Lua解释器，Lua模块（LuaSocks即）链接到一个可执行文件中，该文件将加载.lua脚本。 Lua有“require”系统，期望.dll找到，所以我想知道我应该做什么，仅仅调用没有“require”语句的函数就足够了。
I need to make portable application, that will run on Windows, Linux, MacOS and no install required. It must be one executable file and no other library files (.dll, .so ...). I will use ANSI C and recompile project for each platform. I want to use Lua scripts, so must embed Lua interpreter in my code. I need network and some other modules to write but i now that Lua already have modules for that purpose, so I will use them instead writing my own.
How can I link all that together, Lua interpreter, Lua modules (LuaSocks i.e.) in one executable file that will load .lua script. Lua has "require" system that expects .dll to find, so I wondering what I should do, is it enough just to call functions without "require" statement.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您肯定可以做到这一点（而且这并没有错！），尽管这并不是微不足道的。 Lua 核心是为嵌入而设计的，您只需将 Lua 源代码包含到您自己的项目中，它就可以“正常工作”:)。
模块的情况略有不同——没有多少模块适合直接嵌入。例如，之前已经对 LuaSocket 尝试过成功还有在这里询问。基本思想是将 MODULE 的源代码嵌入到您的项目中，并将
luaopen_MODULE函数插入到package.preload['MODULE']中，以便requirecode> 稍后可以领取。一种方法是查看已经嵌入 Lua 和其他库的项目源，例如 LÖVE、MurgaLua 和 斯克鲁普。
如果没有没有外部库的单个可执行文件的目标无法实现，那么您可以放松一点并选择便携式应用程序 - 一个在单个应用程序中携带所有依赖项的应用程序目录，独立于系统。这就是 LuaDist 的设计目的 - 您可以像 LuaRocks 一样使用它来安装 Lua 软件包。不同之处在于，这些包可以安装/部署到单独的目录中，所有必要的依赖项也都安装在其中。该目录（“dist”）是完全独立的，这意味着您可以将其移动到其他位置，它仍然可以工作。
另外，我不喜欢需要安装的应用程序（因为它将文件放在我的系统中） - 卸载应该只是删除一个目录:)
You most certainly can do that (and it is not wrong!), although it is not trivial. The Lua core is made for embedding, to the point that you can just include the Lua sources into your own project and it "just works" :).
The deal is slightly different with modules - not many of them are suited for direct embedding. For example, this has been tried successfully for LuaSocket before and also asked here. The basic idea is to embed the sources of MODULE to your project and insert the
luaopen_MODULEfunction intopackage.preload['MODULE'], so thatrequirecan pick it up later.One way to go is to look at sources of projects that already embed Lua and other libraries, like LÖVE, MurgaLua and Scrupp.
If the goal of not having a single executable with no external libraries turns out not achievable, you can loosen up a bit and go for portable application - an application that carries all it's dependencies with it, in a single directory, independent of the system. This is what LuaDist was designed for - you use it similar to LuaRocks to install Lua packages. The difference is that these packages can be installed/deployed into a separate directory, where all necessary dependencies are installed too. This directory (a "dist") is fully independent, meaning you can move it somewhere else and it will still work.
Also, I dislike the idea of an application that requires installation (because it puts files all around my system) - uninstallation should be just removal of a directory :)
我相信你不能那样做（而且我认为这样做是错误的）。可执行文件是特定于操作系统和机器的（在 MacOSX 等某些系统上，有 fat 二进制 可执行文件，它们是相同操作系统的各种机器特定变体的组合。）。
拥有系统和功能的唯一途径机器“独立”程序本质上是将其定位于某个单一的通用“虚拟机”（最广泛的意义上）。在你的情况下，这个虚拟机是 Lua 虚拟机（对于其他虚拟机来说，它可能是 Java 虚拟机等）。但你必须假设你的用户拥有它，或者提供一个机器和设备。系统特定。
我个人不喜欢不可安装的应用程序的想法（因为它不容易卸载）。
I believe you cannot do that (and I think it is wrong to do that). An executable is operating system and machine specific (on some systems like MacOSX, there are fat binary executables, which are a mix of various machine specific variants for the same operating system.).
The only way to have a system & machine "independent" program is essentially to target it to some single common "virtual machine" (in the broadest sense). In your case this VM is the Lua VM (it could be the Java VM for others, etc.). But you have to suppose that your user have it, or to provide one which is machine & system specific.
And I would personally dislike the idea of an application which is not installable (because it is then not easily uninstallable).