
Build2, a Cargo-like dependency and build manager for C/C++ - firebacon
https://build2.org/build2-toolchain/doc/build2-toolchain-intro.xhtml
======
quietbritishjim
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/](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.

[1] [https://github.com/Microsoft/vcpkg](https://github.com/Microsoft/vcpkg)

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

~~~
ploxiln
This is exactly what linux distributions do. Big ones with lots of
contributors package around 10k libraries themselves. Small one-man shows
package at least a few hundred common c / c++ libraries.

This is also why I'm not terribly interested in these language-ecosystem
package managers. Good C libraries, such as I use in my own C projects, keep a
stable backwards-compatible interface for _years_.

~~~
orbifold
Any sufficiently large software project can't rely on the distribution to
provide anything for them. The macOS and windows application distribution
models are much saner in that regard. The goal should be a self contained,
easily reproducible build with minimal external system dependencies. This is
why build systems like bazel are so great: They force you to be very explicit
about what you depend on and give you a stable and reliable way to reproduce
your build once you've specified that.

~~~
umanwizard
> Any sufficiently large software project can't rely on the distribution to
> provide anything for them.

This is factually wrong. I'm able to compile things as complicated as
clang/llvm, firefox, and LibreOffice relying mostly on dependencies installed
through the distribution's package manager.

~~~
exDM69
The distro package manager is there to provide your day to day apps and the
libraries to support it.

Sooner or later you will run into an issue where your development work will
depend on a (version) of a library that will break an app you depend on.

Or you will need two versions of a library for your previous and next release
which both need maintenance.

Nor do they provide reproducible builds and other features that are needed for
serious work.

Distro package managers are not suited for development and dependency
management. They might work most of the time, but that is not good enough.

~~~
erik_seaberg
The distro package manager is there to offer a menu of compatible known-good
dependencies that you can readily adopt. It's a ton of work you don't need to
do. If instead you bundle random stuff committed last month, you should have a
compelling reason for beginning to maintain a half-baked distro all by
yourself.

------
chpatrick
The best experience I've had so far with C++ dependency management is with
Nix: [https://nixos.org/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.

------
Ne02ptzero
How does one submit a new package to [https://cppget.org](https://cppget.org)?
I can find a 'Submit' button or documentation about this.

~~~
boris
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](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).

~~~
thespirit
> Currently you will need to email

Oh

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

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

~~~
mdip

        I don't think it clearly beats my current solution of hacking something together from scratch in a couple hundred lines of Python.
    

I've so thought this more than a few times[0]. Every single time I run into
something on my two miserable projects that rely on Hunter, I invariably find
myself wondering why I don't just undo all of the bullsh!t and use the zsh
scripts I threw together for the two projects that I _never_ have build/build
dependency issues with. I believe that, at some point, every native developer
writes something like this. It's funny to think that due to this circumstance
there are probably more build tools available for C/C++ than there are
packages in all of the mainstream C/C++ dependency management systems[1].

[0] Though I tend to use bash (well, more often, zsh), rather than Python.

[1] And probably all of them have a Boost package...

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

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

~~~
hoistbypetard
Could you expand on this a little? I've dabbled with go build, but it didn't
make me want to run screaming away from CMake. Where do you think it's not
doing the right thing? I really like that it can generate project files that
let me use the most useful debuggers on whatever platform I'm targeting. I
think some aspects of its scripting language are a challenge to work with, but
that has felt like a small price to pay for being able to easily work/debug in
VS on Windows, Xcode on Mac, etc.

~~~
jupp0r
* lack of dependency management

* no concept of versions to declare API compatibility

* no easy way to hook into a central package repository

* source files to build have to be named manually in CMakeLists.txt

* header dependencies can easily be wrongly declared, which is never noticed

* the language is hard to work with

* it's quite slow for large projects (10s of thousands of compilation units)

* cross-language builds are a pain (C++ + JS)

I'm not saying this is all CMake's fault, I really like it for the reasons you
outlined. At work, we are transitioning to Bazel to get rid of some of the
pain points above, although it has different problems.

Having worked on some larger Go and Rust projects, I find the integration of
language and build tools to be fantastic to work with and wish the C++
community would come up with a practical solution (probably involving Modules
TS) at some point.

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

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

~~~
sanlyx
From the actual home page ([http://build2.org](http://build2.org)):

    
    
      Next-generation, Cargo-like integrated build toolchain for 
      C++.

~~~
jupp0r
Thanks for clarifying.

------
nickez
Is this related to boost b2 build system?

[https://boostorg.github.io/build/](https://boostorg.github.io/build/)

------
anordal
Sounds like what Meson is.

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

