Xmake and C/C++ Package Management(github.com)
github.com
Xmake and C/C++ Package Management
https://github.com/xmake-io/xmake/wiki/Xmake-and-Cplusplus--Package-Management
23 comments
> I don't know why anybody would want to introduce Node style dependency hell into any C++ project when "configure" exists
More properly, autotools exists. There are reasons CMake has largely taken over from autotools, despite the considerable problems CMake has. I imagine CMake's far superior Windows support might be the main reason.
More properly, autotools exists. There are reasons CMake has largely taken over from autotools, despite the considerable problems CMake has. I imagine CMake's far superior Windows support might be the main reason.
> there are already many powerful C/C++ package managers, the most well-known and most used are: vcpkg, conan, conda, etc. Although they are very powerful, they have a common problem: The build system doesn't have built-in support for them.
CMake supports pkg-config, for what that's worth.
CMake supports pkg-config, for what that's worth.
I think this honestly undersells cmake on this front. CMake's ExternalProject[1] and FetchContent[2] features basically combine into a package manager, letting you pretty seemlessly incorporate things from arbitrary places, especially if they themselves use cmake.
[1] https://cmake.org/cmake/help/latest/module/ExternalProject.h... [2] https://cmake.org/cmake/help/latest/module/FetchContent.html
[1] https://cmake.org/cmake/help/latest/module/ExternalProject.h... [2] https://cmake.org/cmake/help/latest/module/FetchContent.html
> CMake supports pkg-config, for what that's worth.
And in CMake support for Conan is literally a single line of code: conan_basic_setup()
https://docs.conan.io/en/latest/getting_started.html
On top of all this, it's really mind-boggling how a build system's main selling point is doing something a build system has no business doing.
And in CMake support for Conan is literally a single line of code: conan_basic_setup()
https://docs.conan.io/en/latest/getting_started.html
On top of all this, it's really mind-boggling how a build system's main selling point is doing something a build system has no business doing.
And so does Meson. I don't think the xmake author spent a lot of time using other build systems (in fact their short paragraph about Meson demonstrates that they clearly never did use that, using vcpkg with Meson is like 0 effort), it's pretty trivial to simply install a library with "vcpkg/conan install whateverlib" and then use it in your build system via the standard "find_package" (CMake)/"dependency" (Meson) mechanism of adding dependencies.
> In addition, there is another problem, that is, we need to additionally call the vcpkg install [packages] command to install this package. > > Each of these links requires an additional exploration process for users, and it is impossible to achieve real one-click compilation.
And personally I don't think that this "real one-click compilation" should be a goal. On the contrary, I think the current process is pretty much exactly how it should work - first you install your dependencies via your package manager, then you can inspect/vet/whatever them if you want, and then you let your build system build.
> In addition, there is another problem, that is, we need to additionally call the vcpkg install [packages] command to install this package. > > Each of these links requires an additional exploration process for users, and it is impossible to achieve real one-click compilation.
And personally I don't think that this "real one-click compilation" should be a goal. On the contrary, I think the current process is pretty much exactly how it should work - first you install your dependencies via your package manager, then you can inspect/vet/whatever them if you want, and then you let your build system build.
cmake does provide support for conan and other C/C++ ecosystem tools via plugins. It works okay.
I'm not sure adding a layer of Lua helps the situation.
cmake isn't perfect, but the best we have for now. The C++ community has unfortunately been loathe to select a language-wide build tool cum package manager. It's like the early days of Go with all the warring Go dependency systems.
I'm not sure adding a layer of Lua helps the situation.
cmake isn't perfect, but the best we have for now. The C++ community has unfortunately been loathe to select a language-wide build tool cum package manager. It's like the early days of Go with all the warring Go dependency systems.
I didn't buy into the package manager aspect of it, but it's my favorite build tool out of CMake/Bazel/Meson/DDS.
One area where it really shines is if you have a cross-language project. Say you are building a shared/static library in C/C++/Rust/D whatever, and you want to use it in some other language.
In XMake you can set up a build file that can compile the native library in one language, include it in the other language, and then compile that, in like ~10 lines.
Also, it has support for generating CMakeLists.txt automatically, for people that don't want to use XMake. I always commit this to my XMake projects.
One area where it really shines is if you have a cross-language project. Say you are building a shared/static library in C/C++/Rust/D whatever, and you want to use it in some other language.
In XMake you can set up a build file that can compile the native library in one language, include it in the other language, and then compile that, in like ~10 lines.
Also, it has support for generating CMakeLists.txt automatically, for people that don't want to use XMake. I always commit this to my XMake projects.
> In XMake you can set up a build file that can compile the native library in one language, include it in the other language, and then compile that, in like ~10 lines.
Keep in mind that in CMake, that is done by listing the language in program(some program LANGUAGES CXX OBJC ETC) and afterwards you pass the source file list to add-library or add_executable, and CMake takes it from there.
Keep in mind that in CMake, that is done by listing the language in program(some program LANGUAGES CXX OBJC ETC) and afterwards you pass the source file list to add-library or add_executable, and CMake takes it from there.
Has anyone here used xmake in anger? How did it fare?
I will never touch CMake again for my own projects. Ever. Xmake is extremely easy to use (while still being powerful) and really just works.
The only real downside I've encountered is that it if you want to do something very specific, it can be frustrating to find out how. The documentation can be somewhat unclear or lacking at times (I don't blame the author, their native language isn't English), and there is so little content out there that Google always corrects "xmake" to "cmake" in your searches.
The only real downside I've encountered is that it if you want to do something very specific, it can be frustrating to find out how. The documentation can be somewhat unclear or lacking at times (I don't blame the author, their native language isn't English), and there is so little content out there that Google always corrects "xmake" to "cmake" in your searches.
> I will never touch CMake again for my own projects. Ever. Xmake is extremely easy to use (while still being powerful) and really just works.
That's quite the odd statement. CMake is extremely easy to use, just works, and handles everything at all that everyone needs, from building cross-platform projects comprised of multiple programming languages, tests, dependencies, and even packaging.
In your opinion, what makes xmake worth the trouble?
Let's even put up a concrete example. Say I have a cmake project. It handles dependencies with a mix of ExternalProject_Add(), Conan, and even a stashed folder of vended third-party binaries. Also, it handles tests, and packaging, and it runs in a CICD pipeline that does it all on a couple of target platforms. Why would anyone switch that project to xmake?
That's quite the odd statement. CMake is extremely easy to use, just works, and handles everything at all that everyone needs, from building cross-platform projects comprised of multiple programming languages, tests, dependencies, and even packaging.
In your opinion, what makes xmake worth the trouble?
Let's even put up a concrete example. Say I have a cmake project. It handles dependencies with a mix of ExternalProject_Add(), Conan, and even a stashed folder of vended third-party binaries. Also, it handles tests, and packaging, and it runs in a CICD pipeline that does it all on a couple of target platforms. Why would anyone switch that project to xmake?
I've used it, it was actually so good I donated money to the author.
One of the best build systems I've ever used. The author replied to my question within a day on the Discord.
It's an underrated build system. Easiest thing, and has support for just about every language under the sun baked in, even obscure ones.
One of my favorite features particular to C++ is that you can configure dependencies to use local libraries, vcpkg, or Conan specifically.
Before anyone knocks it, highly suggest giving it a try on your next personal project.
One of the best build systems I've ever used. The author replied to my question within a day on the Discord.
It's an underrated build system. Easiest thing, and has support for just about every language under the sun baked in, even obscure ones.
One of my favorite features particular to C++ is that you can configure dependencies to use local libraries, vcpkg, or Conan specifically.
Before anyone knocks it, highly suggest giving it a try on your next personal project.
> One of my favorite features particular to C++ is that you can configure dependencies to use local libraries, vcpkg, or Conan specifically.
This was the only substantiated claim you made in your whole post, but it refers to stuff that most standard build systems already do, specially cmake.
In fact, it's even trivial to hack together a plain old Makefile to add a target that invokes vcpkg or conan to fill in dependencies.
What exactly do you believe makes xmake worth the trouble?
This was the only substantiated claim you made in your whole post, but it refers to stuff that most standard build systems already do, specially cmake.
In fact, it's even trivial to hack together a plain old Makefile to add a target that invokes vcpkg or conan to fill in dependencies.
What exactly do you believe makes xmake worth the trouble?
used it briefly, seems great to me.
it needs some big sponsorship to be mainstream, a very promising project, best wishes.
it needs some big sponsorship to be mainstream, a very promising project, best wishes.
In order to Xmake reach the mainstream, it needs to be supported by major IDEs. The major advantage of CMake over all other building systems is the broad range of IDE support. One can open CMake project without even touching the command line with Visual Studio Code, Visual Studio IDE, Eclipse IDE, Clion or Qt Creator and immediately get support for code exploration, code completion, refactoring and so on.
Xmake has Clion/IDEA, vscode, vs, sublime and qtcreator plugin.
But they are not officially supported plugins, while CMake has official support from major companies and IDE makers, namely Microsoft, Jetbrains, Qt Company. Further comments in this threads also pointed out that some Plugins for Clion are abandonware and may no longer work.
A reason for using Cmake is that this build system's CMakeLists.txt also works like a universal IDE-agnostic project file that saves the user from wasting time tinkering IDEs and lots of XML files in the case of Visual Studio MSBUILD building system.
A reason for using Cmake is that this build system's CMakeLists.txt also works like a universal IDE-agnostic project file that saves the user from wasting time tinkering IDEs and lots of XML files in the case of Visual Studio MSBUILD building system.
> Xmake has Clion/IDEA, vscode, vs, sublime and qtcreator plugin.
Correct me if I'm wrong, but a quick search for Clion's support for xmake only returns a dead plugin from intellij which was last updated 4 years ago.
https://plugins.jetbrains.com/plugin/10156-xmake
Meanwhile, Clion is built around cmake. Why would any Clion customer want to drop first-class support for cmake to fall back to an unmaintained plugin that seems to be abandonware?
Correct me if I'm wrong, but a quick search for Clion's support for xmake only returns a dead plugin from intellij which was last updated 4 years ago.
https://plugins.jetbrains.com/plugin/10156-xmake
Meanwhile, Clion is built around cmake. Why would any Clion customer want to drop first-class support for cmake to fall back to an unmaintained plugin that seems to be abandonware?
I still don't understand what's wrong with writing eg spec files and letting yum/rpm manage the packages. That's what we do where I work.
You don't say. I hear people keep reinventing operating systems in their free time, even. Insane.
Except I personally do not mind this kind of churn. Bring it on, the more the merrier! Having choice is good, and one day someone will strike a gold nugget, no doubt.
Except I personally do not mind this kind of churn. Bring it on, the more the merrier! Having choice is good, and one day someone will strike a gold nugget, no doubt.
Also, being old, I don't know why anybody would want to introduce Node style dependency hell into any C++ project when "configure" exists. https://thoughtbot.com/blog/the-magic-behind-configure-make-...