Hacker News Reader

Comment by jdc | Hacker News Reader

It doesn't depend on Python.

People are downvoting but it’s 100% true. A build system targeting primarily C/C++ requiring an interpreter and runtime dependencies is a no-go for quite a number of projects. There’s a reason they were written in C/C++ in the first place, and the fact that a lot of people install via packages (separating build from distribution) is scarcely solace.

But lua requires a runtime and an interpreter, right?

lua is unique because it can be embedded into C applications as a library, e.g. the difference between SQLite and MySQL.

For example, there's an nginx module that lets you use lua to configure the server logic. I'm presuming you don't need to have lua installed to use xmake (i.e. batteries included), otherwise you're a hundred percent correct.

I don’t get it honestly and never did. On Linux-likes deps are installed by a pm, and chances are you already have python for various reasons. The same goes for Lua. On msw there is more routine, since you don’t have a pm, and have to install everything by hand (+PATH) or choose a pm and begin dealing with its nuances. The same for Lua and xmake. What’s the difference beyond non-C/++ impurity?

I come from FreeBSD where we have an amazing package manager but a “keep it lean” mentality. If a package isn’t on the package manager (the repo is great but nowhere near as expansive as Debian or Fedora) or if I want to build from source, I shouldn’t need to install such a huge system dependency.

Oh, that made me nostalgic of that portupgrade-oniguruma-ruby 20+ minute dep build phase.

In case you’re not aware, the FreeBSD package manager switched to binary packages a while back. No more compilation unless you want to change from the defaults.

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-...

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.

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.

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.

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.

You obviously never had Python PATH hell on windows.

Nope, and I’m pretty sure that I have/had both 3and 2 installed, both in PATH. 3 for experiments and 2 as part if node-gyp toolchain. I can think of why this hell exists — some program calling python.exe gets an incompatible version — but that’s an issue with that program. Linux also had issues with /usr[/local]/bin/python pointing randomly, iirc, didn’t it?

Python can be embedded into C applications as a library.

Reply on news.ycombinator.com