Xmake and C/C++ Package Management

Xmake and C/C++ Package Management(github.com)

39 points by danny0z 4 years ago | 22 comments

I know I'm getting old but the naming of the project really irks me. If it has an "x" in front of it, I expect it needs X Windows and tosses up some kind of gui.

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

MaxBarraclough 4 years ago | |

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

MaxBarraclough 4 years ago |

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

jdrek1 4 years ago | |

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.

stormbrew 4 years ago | |

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

fivea 4 years ago | |

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

mc4ndr3 4 years ago |

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.

gavinray 4 years ago | |

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.

fivea 4 years ago | | |

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

yakubin 4 years ago |

Has anyone here used xmake in anger? How did it fare?

throwaway684936 4 years ago | |

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.

fivea 4 years ago | | |

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

gavinray 4 years ago | |

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.

fivea 4 years ago | | |

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

synergy20 4 years ago |

used it briefly, seems great to me.

it needs some big sponsorship to be mainstream, a very promising project, best wishes.

gwmnxnp_516a 4 years ago | |

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.

danny0z 4 years ago | | |

Xmake has Clion/IDEA, vscode, vs, sublime and qtcreator plugin.

moltke 4 years ago |

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.

Koshkin 4 years ago | |

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.