Show HN: Xrepo – A modern cross-platform C/C++ package manager(tboox.org)
tboox.org
Show HN: Xrepo – A modern cross-platform C/C++ package manager
https://tboox.org/2020/11/15/xrepo-new-command/
27 comments
This probably doesn't help much, but I've researched just about every build system in existence that some very extensive google and github searches could bring up.
Naturally, xmake came up. While I've not used it, and it doesn't really compat with much, it's not the most horribly designed build system out there.
CMake is still the defacto, it allows the most flexibility when needed (albeit very painfully) and provides good-enough support for hierarchical projects.
xmake doesn't solve any of the deficiencies CMake still has, and isn't close to feature parity. Further, it's not improving the 80% use case much over Cmake, which is simple enough for smaller libraries and packages and covers cases like packaging building and installation out of the box without really much extra overhead.
Unless a build system comes along that is 10x better at all aspects, I don't see CMake going anywhere.
Now if Autotools could just die already...
Naturally, xmake came up. While I've not used it, and it doesn't really compat with much, it's not the most horribly designed build system out there.
CMake is still the defacto, it allows the most flexibility when needed (albeit very painfully) and provides good-enough support for hierarchical projects.
xmake doesn't solve any of the deficiencies CMake still has, and isn't close to feature parity. Further, it's not improving the 80% use case much over Cmake, which is simple enough for smaller libraries and packages and covers cases like packaging building and installation out of the box without really much extra overhead.
Unless a build system comes along that is 10x better at all aspects, I don't see CMake going anywhere.
Now if Autotools could just die already...
I feel like everything you just said is true if you replace “cmake” with “make” and “xmake” with “cmake”.
Supporting gcc/clang and msvc with raw make is a pain. That's basically the number 1 CMake value add.
I would add that cmake is a makefile generator.
cmake's value is in the way it provides a high-level abstraction over all supported platflom's capabilities, and that it works by generating and running build scripts from lower level systems such as standard make.
For example, Cmake allows us to set the version of c++ a project uses with a single build target property, which is then used to pick which compiler's flags it uses with a given compiler. It then generates the makefile with all the relevant flags set, and runs that with ease.
This works regardless of platform or compiler.
cmake's value is in the way it provides a high-level abstraction over all supported platflom's capabilities, and that it works by generating and running build scripts from lower level systems such as standard make.
For example, Cmake allows us to set the version of c++ a project uses with a single build target property, which is then used to pick which compiler's flags it uses with a given compiler. It then generates the makefile with all the relevant flags set, and runs that with ease.
This works regardless of platform or compiler.
I agree separating the domain knowledge (CMake, Meson, etc.) from the build plan executor (ninja) is extremely good too, but one must be fair this isn't itself end-benefit to users.
If good architecture was an immediate end-user benefit, we'd get a lot less bad architecture from short-sighted institutions writing code!
If good architecture was an immediate end-user benefit, we'd get a lot less bad architecture from short-sighted institutions writing code!
cmake is just a project generator, it does not have its own build system and package management.
and xmake = make + project generator + package manager
In addition, I don't like cmake's DSL syntax, which is very tedious and difficult to maintain.
and xmake = make + project generator + package manager
In addition, I don't like cmake's DSL syntax, which is very tedious and difficult to maintain.
>>In addition, I don't like cmake's DSL syntax, which is very tedious and difficult to maintain.
I don't agree that Cmake is difficult and hard to maintain.
I do believe that most people write complete messes in their makefile so that they become brittle and hard to maintain.
The so called "modern Cmake" approach, with its declarative approach to project files, is delightful to work with, unlike the old and beaten imperative based path of forcing Cmake to be a glorified scripting language when it never was.
I don't agree that Cmake is difficult and hard to maintain.
I do believe that most people write complete messes in their makefile so that they become brittle and hard to maintain.
The so called "modern Cmake" approach, with its declarative approach to project files, is delightful to work with, unlike the old and beaten imperative based path of forcing Cmake to be a glorified scripting language when it never was.
This. Many PRs that introduce CMake tend to be massive rats nests of configuration slurry that could be summed up in a tenth of the LOC.
What do you mean CMake not working on windows with MSVC / msbuild ? It works fine here with clang and ninja
I've never been able to get it working with clang and ninja on windows. I'll probably go back and fight with it some more, and it's probably as much my fault as CMake's, but a tool that takes that much fighting can be improved.
... what does not work ? provided that you have your ninja and clang binaries in your path, `cmake -GNinja -DCMAKE_CXX_COMPILER=clang++.exe` works fine here
I've used CMake + Intel Compiler too (although that provides same interface as MSVC)
Xmake does not depend on msvc and msbuild at all, it has its own independent build system, and the build speed is as fast as ninja, and on windows, it can use other compilers to compile the project, such as: clang, tinycc ..
> I've been bitten before by tools that are easy for trivial examples and don't work well for larger projects.
Have you looked at build2[1]? One of its main goals is to not make this mistake.
[1] https://build2.org
Have you looked at build2[1]? One of its main goals is to not make this mistake.
[1] https://build2.org
You can use CMake on Windows without MSVC or MSBuild.
I always like hearing about more work in this space. More attention needs to be paid to native language packaging.
That being said, the core problems with current packaging tech don't seem to be addressed here. Though maybe they are and someone can enlighten me.
1. Repo contents are not portable across packaging systems or distributions.
Antipatterns: Often your Makefiles have to be hardcoded to assume pkg-config. Or assume there's a monorepo. Or your CMake has to explicitly mention your packaging system (i.e., Conan::zlib). Or all the projects must be ported to use a particular build system (like CMake exported config packages).
2. Repo contents are not portable across architecturesnand OSs.
There are well known source code anitpatterns here, but per-repo build and packaging specifications still like to have "if windows" and "if ARM" sections. I can live with working around edge cases, but it's really pervasive.
3. Repo contents are not portable across sets of ABI assumptions.
Similar to item 2, but with respect to de facto ABI levers like what language standard is used (libraries often have different ABIs based on language feature detection) or magic preprocessor defines (like which std::string is assumed).
Now, I think the above are hard problems. But I would like to see more folks thinking about them. Especially people researching package management. Especially because someone just wanting to meaningfully use folly or boost::filesystem is generally unaware of the above foot guns.
That being said, the core problems with current packaging tech don't seem to be addressed here. Though maybe they are and someone can enlighten me.
1. Repo contents are not portable across packaging systems or distributions.
Antipatterns: Often your Makefiles have to be hardcoded to assume pkg-config. Or assume there's a monorepo. Or your CMake has to explicitly mention your packaging system (i.e., Conan::zlib). Or all the projects must be ported to use a particular build system (like CMake exported config packages).
2. Repo contents are not portable across architecturesnand OSs.
There are well known source code anitpatterns here, but per-repo build and packaging specifications still like to have "if windows" and "if ARM" sections. I can live with working around edge cases, but it's really pervasive.
3. Repo contents are not portable across sets of ABI assumptions.
Similar to item 2, but with respect to de facto ABI levers like what language standard is used (libraries often have different ABIs based on language feature detection) or magic preprocessor defines (like which std::string is assumed).
Now, I think the above are hard problems. But I would like to see more folks thinking about them. Especially people researching package management. Especially because someone just wanting to meaningfully use folly or boost::filesystem is generally unaware of the above foot guns.
>Antipatterns: Often your Makefiles have to be hardcoded to assume pkg-config.
I'm not clear what you mean here - are you suggesting "hard-coding" use of pkg-config is a bad thing? Why? "Hard-coding" pkg-config would be ideal, I think, since pkg-config is the only package-manager-independent option that I know of for native dependencies...
I'm not clear what you mean here - are you suggesting "hard-coding" use of pkg-config is a bad thing? Why? "Hard-coding" pkg-config would be ideal, I think, since pkg-config is the only package-manager-independent option that I know of for native dependencies...
On paper pkg-config is in the right general direction. Shipping package metadata alongside binaries is probably required to solve the problems I sketched out. And topologically sorting that data makes a ton of sense.
A few problems though:
A. Its model could be more robust. There is no way to specify a language runtime dependency other than providing non-portable linker and compilation flags. Cycles in search paths are easy to introduce, partly because there search paths aren't modeled as such. Instead, flags are just graphed and flattened.
B. To generalize on A, pkg-config very much travels in terms of non-portable flags that you flatten. It would be more useful, arguably essential, to be able to simply export a graph of metadata.
C. In theory pkg-config is portable. In practice, uptake on Windows is underwhelming to be generous. And many Linux distros treat that sort of metadata as optional for native packages as well.
But within a given distro, I have seen pkg-config work well enough. It might be the closest we have to a standard in this space. If the major build systems like CMake and bazel supported exporting cross-compatible .pc files, and then if distros required .pc files (with consistent names!) every time a header was shipped, we would be taking a big step in the right direction.
A few problems though:
A. Its model could be more robust. There is no way to specify a language runtime dependency other than providing non-portable linker and compilation flags. Cycles in search paths are easy to introduce, partly because there search paths aren't modeled as such. Instead, flags are just graphed and flattened.
B. To generalize on A, pkg-config very much travels in terms of non-portable flags that you flatten. It would be more useful, arguably essential, to be able to simply export a graph of metadata.
C. In theory pkg-config is portable. In practice, uptake on Windows is underwhelming to be generous. And many Linux distros treat that sort of metadata as optional for native packages as well.
But within a given distro, I have seen pkg-config work well enough. It might be the closest we have to a standard in this space. If the major build systems like CMake and bazel supported exporting cross-compatible .pc files, and then if distros required .pc files (with consistent names!) every time a header was shipped, we would be taking a big step in the right direction.
Only on unix-like systems, and even there...
> Or all the projects must be ported to use a particular build system (like CMake exported config packages).
They really don't. I mean, it's a nice to have but not a must have.
If you want to use a project that doesn't offer Cmake support then all you need to do is, say, add a find-<projectname>.Cmake file which pretty much just calls find_library and sets a couple of variables, stash it in your project tree under ~/Cmake, add that path to your Cmake modules path and you're all set.
I mean, in all this can be done for each package with less than a dozen lines of code, total.
I'd say not bad.
They really don't. I mean, it's a nice to have but not a must have.
If you want to use a project that doesn't offer Cmake support then all you need to do is, say, add a find-<projectname>.Cmake file which pretty much just calls find_library and sets a couple of variables, stash it in your project tree under ~/Cmake, add that path to your Cmake modules path and you're all set.
I mean, in all this can be done for each package with less than a dozen lines of code, total.
I'd say not bad.
Also see meson's[0] built in package management called wrap-db[1]
[0] https://mesonbuild.com/ [1] https://wrapdb.mesonbuild.com/
[0] https://mesonbuild.com/ [1] https://wrapdb.mesonbuild.com/
Has anybody tried to use Gradle as a C++ package manager?
It seems to be officially supported and gradle is a powerful and decent tool, from experience.
I feel like it's a cultural thing that it doesn't come more often than bazel.
https://docs.gradle.org/current/samples/sample_building_cpp_...
https://docs.gradle.org/current/samples/sample_building_cpp_...
I have, a while ago, so things may have moved on.
It was fun to use to start off with, but I quickly got fed up with Groovy APIs with no intellisense and little documentation.
I certainly helps understanding the Gradle (and even Maven) world first. If you come from that world already, it'll be easy.
edit: I see you can use Kotlin now. That makes it much more interesting IMO.
It was fun to use to start off with, but I quickly got fed up with Groovy APIs with no intellisense and little documentation.
I certainly helps understanding the Gradle (and even Maven) world first. If you come from that world already, it'll be easy.
edit: I see you can use Kotlin now. That makes it much more interesting IMO.
Yup kotlin script has intellisense, the upcoming 6.8 release will make autocomplete much faster (I have to admit it was very slow until recently)
I've been using nix for this, though on windows I assume its WSL only support, maybe mingw
I'd love to find a way fund getting https://github.com/nix-windows/nix over the finish line!
Does anyone have experience with xmake and can offer some perspective on how well it works? CMake not really working on windows without MSVC and MSBuild is still a pain point; I've been bugged by it for a long time but without a viable, cross-platform alternative.
How well does it scale? It looks easy enough to start with, but I've been bitten before by tools that are easy for trivial examples and don't work well for larger projects. Ugly as CMake might be, it works pretty well for big stuff.