The problem with these build tools is never the tool itself (though admittedly I never get far enough to test them). It's the lack of packages in the repositories that back them up. For build2, the central repository is https://cppget.org/ which has 24 packages. 24!! For comparison, npm has more than 600,000 and PyPI has more than 140,000. Now of course not all of those are great quality, but it does illustrate the scale of the problem.
More concretely: As a go-to example for these repos I always look for Google's protobuf library. Most projects I work on depend on three or four high-level libraries which, in turn, depend on protobuf; if even protobuf isn't there (as is the case at cppget.org) then it's hopeless that those higher-level libraries will be.
So far, the best native package manager I've come across is vcpkg [1]. I hate that it's made by Microsoft, and I hate that it uses CMake, but there is no easier to build and use e.g. gRPC on Windows. They recently added Linux and Mac support (static linking only). Edit: for fair comparison, it has just over 700 packages.
I don't believe we can get to thousands of packages by packaging a substantial part ourselves -- we will just get bogged down in this instead of building a decent toolchain. Instead, the "secret" I believe is to make creating, testing, and publishing C/C++ packages as easy and frictionless as possible. This is how you get to thousands of packages and this is what we are trying to do.
Not only are there only 24 packages, 8 are related to build2 itself. cppget has been around since 2016, and at this point I feel it's safe to say it's dead in the water.
The problem is that there isn't a nice way in C++ to separate modules into discrete, importable components the same way that you can in Python, JS, and others. This leads to fractured imports and strange build processes.
Having a large body of existing packages would be nice, but if this can be used with a private repository, it's be hugely valuable to me even if it had no open source packages available at all. I work in a corporate context where projects frequently have multiple complex internal proprietary dependencies. The hacks and workarounds I've seen just to get a sane build up and running in this context are unbelievable. After having used Cargo for some personal projects, I yearn for a similar tool in the C / C++ landscape.
My best experience with a build tool has been FB's Buck (buckbuild.com), half for it not limiting you to just C/C++, and half for buckaroo (buckaroo.pm) making installs of common packages--like protobuff--easy.
I find that the second limiting factor I hit is being able to easily interop with other languages and to cross-compile for other platforms. Buck makes that super easy, too.
I upvoted you. But what is wrong with being made by Microsoft? When the license is great.
But I agree with the CMake part. CMake is abomination. CMake is diabolical. But it is not vcpkg problem. It is C++ community program. They chose CMake because it was the facto build system for most packages.
--- While your point is completely fair in that 24 packages won't make a very useful service, it's also fair to say this is a new tool and it's OK to give it some time. --- (EDIT: for the sake of transparency, I'm crossing out this initial paragraph since, after reading some other comments, I've discovered that cppget isn't all that new; the rest of my comment, however, is relevant without that statement)
I'll poke a little at your assertion that it's "never the build tool itself". Unfortunately, in my experience, it often is. Have a nice fight with Hunter in a project or two. It's got a decent, though still somewhat small, number of packages[0], but that doesn't make it useful. Every time I reload my PC and clone the two repos that rely on it, I invariably spend a day sorting out something or another (last time it was signature related). It doesn't help that the tool is tied to CMake, these are the only two repos I use that rely on CMake and I have actively avoided learning enough about it to not require several Google searches when I need to do somewhat simple things, but that's the rub. Cargo is simple, even npm (by comparison) is simple even for projects with great complexity[1]. Hunter, by comparison, has me asking every single time I have to update a dependency or install fresh from a clone ... what problem is this solving for me? How is this less manual than managing dependencies with a clever zsh script[2]?
As far as vcpkg is concerned, I agree, though I'm a Microsoft fan[3]. It generally works -- and unlike Hunter, which uses CMake as well, I haven't run into the kind of hair pulling, four-letter word spewing fits using it ... at least not to the extent that I did.
To the authors: Really, though, please please keep investing in making better dependency management tooling. If it's good enough, there are enough of us that will make "unofficial packages" because it takes less time to figure that out than it does to figure out how to fix the broken dependency management system we're stuck with.
[1] I'm certainly not saying it's not without its pointy corners, but I'll take those sharp edges any day over some of the C++ build tools I've played with.
[2] Which is the only "build dependency management" system that's worked for me -- I literally "lynx --dump" the releases page, parse for URLs, download and script out each build dependency manually ... I even have a set of functions that manage to do some of this in a relatively well abstracted manner given the circumstances. Granted, these are single platform target apps, but so are the handful I have that use vcpkg.
[3] Well... to be fair, my one Windows 10 install is in a virtual on an openSUSE Tumbleweed installation, so maybe I'm not a fanboy, but with their movement towards open sourcing a lot of their tooling and frameworks, there's not a lot I can complain about, personally.
The best experience I've had so far with C++ dependency management is with Nix: https://nixos.org/nix/
It has a very large collection of packages already available, supports many existing build systems (CMake and autotools work out of the box, but you can hook up anything), and can download binary packages for almost everything.
Good question. Currently you will need to email a git repository URL and tag you want published (e.g., https://git.build2.org/hello/libhello.git#v1.0.0) and we will publish it for you (or you can provide a package archive if you prefer).
For the next version we plan to implement a CI/CD bot which will poll your git repository for tagged versions and automatically test and publish them to cppget.org (there will be some sort of a control file that you will be able to use to specify which tags should be published where, etc).
I’ve been using Conan.io for a bit. I come to c++ from ruby ang golang—both of which have ecosystems with very different dependency management philosophies. It’s interesting to see these various tools arrive in the c++ ecosystem. There’s clearly not a winner yet.
I think vcpkg is the clear winner for people who just want to get started building something. It's the fastest way to get a ton of common packages built and installed.
For more delicate maintenance of stable software (which will often need to depend on specific versions, customize builds, etc), it's still a little hazy. Conan looks ok, but I don't think it clearly beats my current solution of hacking something together from scratch in a couple hundred lines of Python.
I don't like making "X technology sucks" posts, and I'll probably get downvoted to oblivion for this opinion, but I'm really rooting for anything other than CMake.
I'm curious if you've ever worked with something like cargo or go build. CMake works well for what it does, but it doesn't do the right things if you've ever seen more modern solutions to the same problem.
Just from a quick read of the page, I couldn't put my finger on why I might choose this over conan + cmake. Could someone who's tried both weigh in on what the relative strengths and weaknesses are?
The submission title is strongly misleading. From the page:
Unlike most other programming languages that encapsulate the
build system, package dependency manager, and project
dependency manager into a single tool (such as Rust's cargo
or Go's go), build2 is a hierarchy of several tools that
you will be using directly and which together with your
version control system (VCS) will constitute the core
of your project management toolset.
Agreed that the title is misleading, but if you look at it does seem a bit like cargo in functionality. Which begs the question: why create this instead of using nix expressions?
[+] [-] quietbritishjim|7 years ago|reply
More concretely: As a go-to example for these repos I always look for Google's protobuf library. Most projects I work on depend on three or four high-level libraries which, in turn, depend on protobuf; if even protobuf isn't there (as is the case at cppget.org) then it's hopeless that those higher-level libraries will be.
So far, the best native package manager I've come across is vcpkg [1]. I hate that it's made by Microsoft, and I hate that it uses CMake, but there is no easier to build and use e.g. gRPC on Windows. They recently added Linux and Mac support (static linking only). Edit: for fair comparison, it has just over 700 packages.
[1] https://github.com/Microsoft/vcpkg
[+] [-] boris|7 years ago|reply
[+] [-] pkage|7 years ago|reply
The problem is that there isn't a nice way in C++ to separate modules into discrete, importable components the same way that you can in Python, JS, and others. This leads to fractured imports and strange build processes.
[+] [-] lyricaljoke|7 years ago|reply
[+] [-] Firecracker|7 years ago|reply
I find that the second limiting factor I hit is being able to easily interop with other languages and to cross-compile for other platforms. Buck makes that super easy, too.
[+] [-] master-litty|7 years ago|reply
[+] [-] 0xFFC|7 years ago|reply
But I agree with the CMake part. CMake is abomination. CMake is diabolical. But it is not vcpkg problem. It is C++ community program. They chose CMake because it was the facto build system for most packages.
[+] [-] mdip|7 years ago|reply
I'll poke a little at your assertion that it's "never the build tool itself". Unfortunately, in my experience, it often is. Have a nice fight with Hunter in a project or two. It's got a decent, though still somewhat small, number of packages[0], but that doesn't make it useful. Every time I reload my PC and clone the two repos that rely on it, I invariably spend a day sorting out something or another (last time it was signature related). It doesn't help that the tool is tied to CMake, these are the only two repos I use that rely on CMake and I have actively avoided learning enough about it to not require several Google searches when I need to do somewhat simple things, but that's the rub. Cargo is simple, even npm (by comparison) is simple even for projects with great complexity[1]. Hunter, by comparison, has me asking every single time I have to update a dependency or install fresh from a clone ... what problem is this solving for me? How is this less manual than managing dependencies with a clever zsh script[2]?
As far as vcpkg is concerned, I agree, though I'm a Microsoft fan[3]. It generally works -- and unlike Hunter, which uses CMake as well, I haven't run into the kind of hair pulling, four-letter word spewing fits using it ... at least not to the extent that I did.
To the authors: Really, though, please please keep investing in making better dependency management tooling. If it's good enough, there are enough of us that will make "unofficial packages" because it takes less time to figure that out than it does to figure out how to fix the broken dependency management system we're stuck with.
[0] https://docs.hunter.sh/en/latest/packages/all.html
[1] I'm certainly not saying it's not without its pointy corners, but I'll take those sharp edges any day over some of the C++ build tools I've played with.
[2] Which is the only "build dependency management" system that's worked for me -- I literally "lynx --dump" the releases page, parse for URLs, download and script out each build dependency manually ... I even have a set of functions that manage to do some of this in a relatively well abstracted manner given the circumstances. Granted, these are single platform target apps, but so are the handful I have that use vcpkg.
[3] Well... to be fair, my one Windows 10 install is in a virtual on an openSUSE Tumbleweed installation, so maybe I'm not a fanboy, but with their movement towards open sourcing a lot of their tooling and frameworks, there's not a lot I can complain about, personally.
[+] [-] chpatrick|7 years ago|reply
It has a very large collection of packages already available, supports many existing build systems (CMake and autotools work out of the box, but you can hook up anything), and can download binary packages for almost everything.
[+] [-] Ne02ptzero|7 years ago|reply
[+] [-] boris|7 years ago|reply
For the next version we plan to implement a CI/CD bot which will poll your git repository for tagged versions and automatically test and publish them to cppget.org (there will be some sort of a control file that you will be able to use to specify which tags should be published where, etc).
[+] [-] bradhe|7 years ago|reply
[+] [-] TillE|7 years ago|reply
For more delicate maintenance of stable software (which will often need to depend on specific versions, customize builds, etc), it's still a little hazy. Conan looks ok, but I don't think it clearly beats my current solution of hacking something together from scratch in a couple hundred lines of Python.
[+] [-] weberc2|7 years ago|reply
[+] [-] jupp0r|7 years ago|reply
[+] [-] hoistbypetard|7 years ago|reply
[+] [-] jupp0r|7 years ago|reply
[+] [-] sanlyx|7 years ago|reply
[+] [-] commandocrypto|7 years ago|reply
[+] [-] nickez|7 years ago|reply
https://boostorg.github.io/build/
[+] [-] anordal|7 years ago|reply
Meson can download other Meson projects. From anywhere (no special repo). And you can use that as a fallback for pkg-config (best of both worlds).