C++ @programming.dev leviosa @programming.dev 1 yr. ago

Xmake v2.8.2 Released, Official package repository count over 1k

github.com Xmake v2.8.2 Released, Official package repository count over 1k

🔥 A cross-platform build utility based on Lua. Contribute to xmake-io/xmake development by creating an account on GitHub.

12 comments

I tried to see what was xmake's value proposition, but even xmake's site fails to present anything. Writing something in Lua is far from a compelling reason to switch a build system.

Why would anyone use xmake over cmake?
- I think it's mostly a cultural thing? I see most Chinese devs prefer xmake, probably out of solidarity because its devs are also Chinese.
  
  As for me, I also don't see the appeal in xmake. CMake, coupled with ninja, just works and for many popular libraries there's a great chance that you can add them to your project simply by doing a find_package because of how popular CMake is. The build systems landscape in C++ is already messy enough and I don't see how introducing yet another CMake-like would improve things. What we need is more .cmake files for popular libraries.
- I'll give some bullet points that might be of interest, I agree that they need a funky infographic or similar.
  
  it's a build system itself, it doesn't need make or whatever and compilation speeds are similar to ninja
  
  which means it can do things like distributed building
  
  and implement local caching, like ccache but supporting msvc as well as gcc/clang (actually msvc might be disabled at the moment)
  
  .. likewise remote caching, like Mozilla's sscache for teams (again supporting msvc/gcc/clang)
  
  it has its own package manager but also works with pretty much all other popular package managers
  
  the build system will default to any matching installed system libs unless you say otherwise ({ system = false} on a per-included package basis)
  
  it downloads and installed necessary packages when first building a project
  
  package manager can use pre-compiled Windows artefacts
  
  can use the hosted online repo, or our own online or local repos (multiple if we want)
  
  location of alternative repos can be set in xmake.lua file or configured on command line (or config file).
  
  can configure project with a TUI menu xmake f --menu
  
  It just feels more straightforward and logical to me too. I know that's subjective, but the objective part of that is it's a unified build system, cache system and package manager that sets out to work with other tools.
  
  (edited: tidied bullet lists)
  
  it’s a build system itself, it doesn’t need make or whatever and compilation speeds are similar to ninja – which means it can do things like distributed building – and implement local caching, like ccache but supporting msvc as well as gcc/clang (actually msvc might be disabled at the moment) – … likewise remote caching, like Mozilla’s sscache for teams (again supporting msvc/gcc/clang)
  
  So it offers nothing over cmake, and at best it matches features already offers for ages, such as transparent support for compiler cachês and distributed compilers.
  
  it has its own package manager but also works with pretty much all other popular package managers –
  
  That lies somewhere between matching cmake's features, and placing users in a losing proposition with its own package manager.
  
  can configure project with a TUI menu xmake f --menu
  
  Not only is this irrelevant but it is also something cmake provides.
  
  Also, cmake is the de facto standard and supported natively by IDEs such as Visual Studio.
  
  Knowing this, why would anyone bother with xmake?
- @lysdexic @leviosa It's always the same with "new" build systems: people think that a new language will make things much easier. But for complex build systems, they then realize how difficult such systems are, which cannot be hidden.
  And about the syntax: that's not important.
- Supposedly easier to use, with less warts than cmake. However it being developed in China makes it a security risk for me personally. And even if it wasn't, I'd probably stick with cmake anyways due to cmake being the big standard
I currently find known C/C++ build systems and package managers lacking. Maybe this is caused by the high bar by Cargo. Its nice to see something similar to Cargo in C/C++ ecosystem. vcpkg and conan are a pain in the ass in my opinion
- Yup, Cargo is a good baseline to compare to. I don't get the CMake arguments since:
  
  xmake isn't trying to replace CMake
  
  xmake can create CMake files from an xmake project
  
  xmake can consume CMake files
  
  xmake can use CMake packages
  
  you can use xmake packages in a CMake project
  
  a lot of people quite obviously don't like CMake
  
  It's working with the ecosystem, not against and is good for C++ especially since people are comparing C++ building with tools like Cargo now.

You've viewed 12 comments.