
Xmake: A cross-platform build utility based on Lua - fanf2
https://xmake.io/
======
imtringued
I don't understand the motivation behind an imperative build system. Why is it
"add_rules(a,b)" instead of just "rule(a,b)"? It's like someone discovered the
benefits of a domain specific language and butchered the concept by making the
internal implementation the public interface. Why does it matter to the user
that something is getting added to something? Why doesn't it look closer to
this [0]?

[0]
[https://repl.it/repls/DeadCalmPrinter](https://repl.it/repls/DeadCalmPrinter)

~~~
HelloNurse
It's imperative in order to allow arbitrary control structures instead of
bending over backwards with 80% solutions and stupid fragile tricks like you
would need with Make.

------
MaxBarraclough
I'm not sure we need _yet another_ build system. We pay a real price for this
sort of fragmentation. If I have to pick up your cross-platform C++ codebase,
I shouldn't have to learn yet another build system.

CMake/autotools/Premake/SCons/waf/Ninja/Meson/GYP/qmake/Bazel... and now
xmake.

I'd rather CMake just be improved, than see endless incompatible reinventions.
If you'll forgive a little snark: on the plus side, it's unlikely this new
challenger will see any real uptake.

~~~
rumanator
I feel you're grossly exaggerating the current state of affairs.

From your list alone, cmake is the de-facto standard. All others are either
defunct, abandoned, or dropped out of favour, or never had any expressive
adoption. For instance autotools is largely a relic of back in the days where
C++ was C with classes, and Qmake was already dropped by their makers in
favour of cmake.

Additionally, some of your entries don't make much sense. For example, ninja
is at most a low level alternative to raw makefiles, and in fact tools like
cmake are able to generate either makefiles or ninja files, and GYP is just a
high-level format designed to generate other build system project files,
specially IDE-specific projects such as XCode and Visual Studio project files.

~~~
mcguire
" _For instance autotools is largely a relic of back in the days where C++ was
C with classes..._ "

Minor point: autotools is a relic of the days when there were multiple, only
somewhat compatible implementation of Unix in common use. Now that the world
is a Linux monoculture and most software is installed by end users in the form
of pre-built binary packages, the form of portability provided by autotools is
no longer needed.

~~~
rumanator
I don't agree with you at all. Autotools boil down to a bunch of shell scripts
that enable projects to abstract away the OS/distribution while following a
somewhat standard structure.

And binary packages are completely irrelevant and unrelated, because autotools
is a build system, thus designed to help build software. Although the
availability of source code packages enabled build systems to be also used as
installers, thay does not mean the need for build systems is replaced with
plain old installers.

------
CountSessine
With years of experience with Scons, I can say quite confidently that I don’t
ever want to work with a Turing-complete build system ever again.

~~~
jcelerier
> I don’t ever want to work with a Turing-complete build system ever again.

so do you instead write custom additional executables that may require a
cross-compilation step for whenever you have to perform custom
pre/postprocessing tasks on your code (e.g. parsing it, etc)

~~~
nickez
And your point is that it would be better to write pre/postprocessing logic
_in_ the build system? That sounds like a recipe for disaster and slow build
times.

~~~
jcelerier
> And your point is that it would be better to write pre/postprocessing logic
> in the build system

well, it has to be somewhere and i'd rather write my build configuration in a
language instead of N. So yes, that's what I do currently and it causes me
exactly zero issues.

------
craftkiller
Looks pretty similar to premake[1] but I couldn't find a comparison on the
site. Could you provide a pitch or comparison? From what I can tell so far, it
looks like xmake directly invokes the build tools whereas premake generates a
Makefile/Xcode project/visual studio project from which you then need to use
those tools to perform the final build.

[1] [https://premake.github.io/](https://premake.github.io/)

~~~
kitd
I've only kicked the tyres of both, but Xmake seems to be more opinionated
than Premake. It gives you quite a lot out of the box that you have to build
yourself in Premake. Eg (basic) dependency management.

Tbh, I was impressed by Xmake. All I need is a meaningful project to use it
on.

------
eska
Benefits over meson? I found no unique features from skimming the docs.

~~~
jdc
It doesn't depend on Python.

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

~~~
SahAssar
But lua requires a runtime and an interpreter, right?

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

~~~
wruza
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?

~~~
pixelmonkey
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-...](https://github.com/xmake-
io/xmake/blob/master/README.md#run-the-custom-lua-script-plugin)

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

