5 ms·

I believe xmake doesn't "require" Lua. Instead, xmake embeds Lua. Specifically it embeds LuaJIT 2.1, based on what I could tell in their repo source. So, when y

I believe xmake doesn't "require" Lua. Instead, xmake embeds Lua. Specifically it embeds LuaJIT 2.1, based on what I could tell in their repo source. So, when you run xmake, you're actually running a a full-blown Lua implementation that is self-contained in the xmake binary, that has some automatic imports for the xmake embedded build DSL. If you want to run arbitrary Lua using xmake, there is a built-in "lua" plugin, shorthand "xmake l", described here: https://github.com/xmake-io/xmake/blob/master/README.md#run-the-custom-lua-script-plugin https://github.com/xmake-io/xmake/blob/master/README.md#run-... So, it would be a bit like if you built a build language atop Python, but rather than depending on Python, you made your whole build tool embed the entire CPython interpreter, pinned to some version. Lua is used in this way more commonly than Python is, of course. So: xmake itself is just a C program with large submodules written in Lua, running inside that embedded Lua context. The upside here is that xmake's releases are just plain platform-specific native binaries that bundle everything you need, and that make no assumptions about your base system. This is a nice benefit in a build tool, as it aids in reproducible builds.

imtringued 7y ago
I have used lua this way myself but I don't understand how installing python is a barrier. I understand that depending on a secondary programming language to build your software is sub optimal because only the person setting up the build system gets familiar with the "build language" and when something breaks that person is the only one that can fix the build. Switching away from python to lua only makes that problem worse because python is more popular than lua.
- wruza 7y ago
  Yes, and this is a big problem. People are unaware how other lang’s environments work. This exact issue I have with AutoHotKey app. Instead of taking something popular, it reinvented its own cryptic language and its author seems to be attached to it to not even think to support other runtimes. Many things I’d like to do in AHK, but this wall is hard. Even if you learn a language, without practice it fades rapidly, and next time you return there it’s still the same cryptic copy-paste cookbook.
wruza 7y ago
I embedded Lua both ways (.a vs .dll). Not sure now, but I think that it is then ~thing in itself and require()-ing external dlls will mess with your runtime badly, but again it was some time ago and maybe there was a way to export .exe api to 3rd-party dlls instead of lua5x.dll found somewhere in path. Anyway, a single executable makes it hard to argue, and in this case I agree with you and ggp.

imtringued 7y ago

I have used lua this way myself but I don't understand how installing python is a barrier. I understand that depending on a secondary programming language to build your software is sub optimal because only the person setting up the build system gets familiar with the "build language" and when something breaks that person is the only one that can fix the build. Switching away from python to lua only makes that problem worse because python is more popular than lua.

wruza 7y ago
Yes, and this is a big problem. People are unaware how other lang’s environments work. This exact issue I have with AutoHotKey app. Instead of taking something popular, it reinvented its own cryptic language and its author seems to be attached to it to not even think to support other runtimes. Many things I’d like to do in AHK, but this wall is hard. Even if you learn a language, without practice it fades rapidly, and next time you return there it’s still the same cryptic copy-paste cookbook.

wruza 7y ago

I embedded Lua both ways (.a vs .dll). Not sure now, but I think that it is then ~thing in itself and require()-ing external dlls will mess with your runtime badly, but again it was some time ago and maybe there was a way to export .exe api to 3rd-party dlls instead of lua5x.dll found somewhere in path. Anyway, a single executable makes it hard to argue, and in this case I agree with you and ggp.