10
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 26 Aug 2023
10 points (91.7% liked)
C++
1763 readers
1 users here now
The center for all discussion and news regarding C++.
Rules
- Respect instance rules.
- Don't be a jerk.
- Please keep all posts related to C++.
founded 1 year ago
MODERATORS
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_packagebecause 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.cmakefiles for popular libraries.@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.
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
it has its own package manager but also works with pretty much all other popular package managers
{ system = false}on a per-included package basis)can configure project with a TUI menu
xmake f --menuIt 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)
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.
That lies somewhere between matching cmake's features, and placing users in a losing proposition with its own package manager.
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?
In your opinion, I'd say the overall integration and being an actual build system are offerings for starters.
It also supports other languages like Zig, Pascal and Rust too. Here's an example of C++ calling Rust, note the easy inclusion of Cargo crates...
https://github.com/xmake-io/xmake/tree/dev/tests/projects/rust/cxx_call_rust_library
xmake is just nicer, more concise and 100% less shouty. People in general use cmake because it's the de facto standard, not because they like cmake and its DSL.
xmake can generate cmake files too so it's not going against the grain. There are plugins for popular IDEs as well.
Not really. It's yet another build system whose main aspiration is to eventually match cmake's capabilities but missing all the reasons that made cmake the de facto standard, such as the declarative straight to the point way of specifying targets.
And yet lots of people use xmake and other alternatives....
Define "lots".
Also, your weekend pet project is not the same as a corporation's cash cow.
Close to half of C++ developers in that survey regularly use something other than CMake and I've seen projects at Microsoft and Epic Games use xmake. Why are you being such a pecker?