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

[Weasel]

boris-kolpackov I have never heard of build2 and it seems amazing already, even without the package management thing people are crying about.

Also, THANK YOU for not making it depend on more crap like Python, that is a HUGE DEAL for some of us (especially those building on isolated, minimalistic containers). I hope your project succeeds and I will definitely spread the word about it!

Build dependencies for the actual build tools are the source of so much frustration. (a C++ compiler is required, anyway, to build the project, so it doesn't matter)

[Weasel]

Why reinvent Meson, just differently?

Because Meson requires Python so it will forever suck.

[Luke_Wolf]

C++ Build systems finally brought to the 21st Century? Sign me up.

also boris-kolpackov I wouldn't be too worried about rene, he just trolls any topic to do with rust.

[andreano]

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

Meson subprojects (aka. wrap) does support version resolution, git and archive-based repositories. And it supports one killer feature that no other packaging system supports (correct me if I'm wrong): Using installed dependencies with fallback to a bundled or downloaded subproject. I call that superior to Cargo.

Native build system instead of a meta/project generator.
No Python dependency, all you need is a C++ compiler.

Fine, just different. Might as well reimlement Meson, if only to avoid these.

EDIT:

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.

Now, you are convincing me! This is the killer feature that only Meson supported until now!

[eltomito]

This sounds awesome! I hope it works

[kpedersen]

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

Of course I'm not. For example the Raspberry Pi running Rasbian (armv6) has *one* version of SDL2. Running OpenBSD (aarch64), it has *one* version of SDL2.
You link against those versions installed. You don't want to bundle up a bunch of dependencies for your deployment target. If you are looking at some proprietary devices such as phones and game consoles, many of these you don't have a say in anyway.

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

I am hoping not but it is looking that way. And it simply means that it won't take off and we will stick to what we have now (which certainly has its own set of issues) and we have failed to solve anything.

I feel we need a whole new fresh approach to dependency management rather than.... ooh, NPM is great, lets copy that and let it break in a few months.

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

I don't believe that is possible. Is Build2 really going to maintain "bindings" against all known package managers such as apt, yum, dnz, pkg, pkgng, yast, ipa, apk, and countless others? And for each toolchain combination? Doubtful.

And more importantly, will it support each package system for the entirety of a project + maintenance lifespan (~4-8 years)?

I imagine developers might wait on this one first before jumping on board. All the other features beyond the slightly naive dependency management look good though. I think it is a very worthwhile project for some of those features alone.

[andreano]

> not to replace the system package managers but to complement them.

Is Build2 really going to maintain "bindings" against all known package managers?

I get it. He said pkg-config. If it works like Meson, then you can make it download dependencies just as a fallback for missing dependencies on the system.

This way, you can satisfy both casual users who just want to build the thing and wouldn't mind a bit of static linking, and you make life easy for distro packagers who want to make sure everything is dynamically linked.
Or on the workplace: The CI system may want to build in a docker container that has all dependencies preinstalled, but you don't want to force your colleagues to build in docker just because the buildsystem is inflexible.

This is a killer feature I would support, no matter if it's called Meson or Build2.

CMake is sorely lacking this. It has ExternalProject_Add, but that doesn't work with find_library, which defeats any modern CMake use. The modern equivalent is FetchContent, but that always downloads, which is not what we want either.

[kpedersen]

The modern equivalent is FetchContent, but that always downloads, which is not what we want either.

I have started to see this one crop up. It will fetch the vanilla sources and then basically fail to build on almost all platforms. For example Debian and FreeBSD needs a number of patches to sources to fix broken assumptions in library build systems. Even relatively fundamental and stable libraries such as SDL2 (https://svnweb.freebsd.org/ports/hea...l/sdl20/files/). Ironically many Linux distros require even more patches for some software than *BSD even though it is a more common platform :S.

So if a language based dependency manager doesn't utilise the native package manager (i.e CMake's FetchContent), then it is almost useless for professional development.

NPM doesn't really have this issue because it only supports 2 platforms. Node.js and Web browser so it can be naive. I believe this is where this fairly incorrect solution to dependency management comes from. Likewise it almost works for Rust's cargo because all the really important cross platform code is delegated to C or C++ anyway. This wont always be the case but they do need to solve this problem before it can be.

[andreano]

needs a number of patches to sources

Right. I've been there with FetchContent as well. Build instructions were like stop the build and apply this patch.

But guess what, Meson supports patches: https://mesonbuild.com/Wrap-dependen...em-manual.html

[jjkk]

boris-kolpackov I have never heard of build2 and it seems amazing already, even without the package management thing people are crying about.

Have you ever heard of build tools at all?

Also, THANK YOU for not making it depend on more crap like Python, that is a HUGE DEAL for some of us (especially those building on isolated, minimalistic containers). I hope your project succeeds and I will definitely spread the word about it!

Build dependencies for the actual build tools are the source of so much frustration. (a C++ compiler is required, anyway, to build the project, so it doesn't matter)

Ever heard of cross building?

Because Meson requires Python so it will forever suck.

Yeah, instead of depending on an established and accepted tool which you have in any possible distro, let's depend on a new and shiny hipster crap which you'll need in your "minimalistic" container to build another crap package. Sounds like a win.

Yet another garbage for those, who have no idea about existing tools and practices and want their crappy hello_world.cpp projects to build "magically" without thinking how their system work and how software works at all.