Build2 v0.13 Released As C/C++ Build Toolchain Inspired By Rust's Cargo

[phoronix]

Phoronix: Build2 v0.13 Released As C/C++ Build Toolchain Inspired By Rust's Cargo

Version 0.13 of the Build2 build toolchain is now available, the open-source project inspired by the Rust programming language's Cargo system but instead tooled for C/C++ while serving not only as the build system but also a package and project manager...

http://www.phoronix.com/scan.php?page=news_item&px=Build2-0.13-Build-System

[andreano]

Why reinvent Meson, just differently?

Edit, for those that may not know:

Meson has package management too! Even some killer features that Cargo doesn't. Which is why I was so underimpressed after reading that FAQ. Now, I see it as equally good.

[boris-kolpackov]

Just like Meson, in other words.

Very different from Meson, in fact. Just to name a few major differences:

1. Native build system instead of a meta/project generator.
2. Comes with a proper package/project dependency manager (proper versioning, resolution, git and archive-based repositories, etc). AFAIK, Meson has something very rudimentary called "wrap" (but do correct me if I am mistaken).
3. No Python dependency, all you need is a C++ compiler.

[kpedersen]

build2 is a hierarchy of tools consisting of a general-purpose build system, package manager (for package consumption), and project manager (for project development). It is primarily aimed at C/C++ projects as well as mixed-language projects involving one of these languages (see bash and rust modules, for example).

These package managers are fairly pointless. Since C and C++ is the dominant programming language, the systems native package manager is surely best to use. This kind of language based package manager just encourages sloppy development, encouraging an undisciplined developer to drag in pointless dependencies due to sheer lazyness rather than a decent integration. Everyone codes like a web developer basically XD

The requirement of a language package manager by Rust's cargo is possibly one of the only reasons that I think Rust may fail to replace C++.

[discordian]

build2 is a hierarchy of tools consisting of a general-purpose build system, package manager (for package consumption), and project manager (for project development). It is primarily aimed at C/C++ projects as well as mixed-language projects involving one of these languages (see bash and rust modules, for example).

These package managers are fairly pointless. Since C and C++ is the dominant programming language, the systems native package manager is surely best to use. This kind of language based package manager just encourages sloppy development, encouraging an undisciplined developer to drag in pointless dependencies due to sheer lazyness rather than a decent integration. Everyone codes like a web developer basically XD

The systems native package manager is fairly useless if you need different version, (and potentially your dependencies need the same library, but different version). Even worse if you want to support multiple systems or are crosscompiling.
Also for automated builds you typically dont want to allow root access.

Its kinda pointless to have multiple managers though, conan seems poised to become the dominant, build-system agnostic dependency managers.

[kpedersen]

The systems native package manager is fairly useless if you need different version.

Well you need to make sure that you can use the version provided by the platform. I.e most Unix-like platforms provide one version of a library in their package manager (i.e SDL2-2.0.12), it is bad practice to not link against that and instead provide your own version. Not everything can be statically linked either.

Yes, on Windows you bundle up *all* the program dependencies (which admittedly I prefer, closely followed by Solaris's /opt/csw, /usr/sfw, etc), but this isn't the general practice on *nix. This is why things like Flatpak and docker have appeared I suppose.

[discordian]

Well you need to make sure that you can use the version provided by the platform. I.e most Unix-like platforms provide one version of a library in their package manager (i.e SDL2-2.0.12), it is bad practice to not link against that and instead provide your own version. Not everything can be statically linked either.

You are assuming that the platform you are compiling on, is the same that the code will run on.

[boris-kolpackov]

Since C and C++ is the dominant programming language, the systems native package manager is surely best to use.

I think the reasons why a system package manager may not be sufficient for development have been adequately addressed. So I just want to point out that build2 makes sure it integrates well with system package managers.

Specifically, it is a toolchain consisting of a hierarchy of tools: the build system, the package manager (for package consumption), and the project manager (for project development; things like versioning, release management, CI, etc). So if you want to track the dependencies yourself (as a distribution packager would), then you can disregard the package manager and use the build system directly.

The build system will also happily use a system-installed library; there is even pkg-config integration to extract additional information such as the location of headers, additional libraries to link, etc. Also, the package manager has a notion of system-installed packages which allows you to instruct it to assume the package is available from the system rather than building it from source.

So, to sum up, the goal is not to replace the system package managers but to complement them.

[rene]

yeah, well, taking the worst and most annoying of Rust, ... no thanks ;-)

[boris-kolpackov]

yeah, well, taking the worst and most annoying of Rust, ... no thanks ;-)

Could you elaborate on this? Specifically, what annoying parts of Cargo do you believe were carried over to build2? I am genuinely curious because we tried hard not to repeat some of the major (IMO, of course) mistakes of Cargo, such as lumping the build system and the package/project manager into a single tool or only supporting build by convention without a general build system (which leads to "build scrips" in the form of build.rs). Thanks in advance!