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

[discordian]

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.

So, how would you compile a program for the Raspian, from OpenBSD?
Thats where dependency management comes in, ideally you DL a source package on *any* platform and can compile for *any* target and dont inadvertently use mismatched headers/libraries from the host.

This is completely independent from installing stuff for your host, it makes sure you get the dependencies your target needs, whether these are DSO or static libs.

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.



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.

It wont replace apt, rpm, etc. its a tool for developers building stuff. It allows you to use software that's not available in the right version to build stuff, not necessary run it.
I am using CMake + Conan and the project is a normal CMake project which just uses the normal method to find stuff (find_package, etc).

Run normally, it will resolve the host's libraries. If I run conan before it will download or compile dependencies, prepare them in a folder in your subdirectory and generate a configfile so CMake finds them. The only difference to a "pure" CMake project is that I include that generated configfile if it exists.
If id push this package into, say debian, it would use the distros way of fetching dependencies. Again, this is purely a developer tool.

And if you build a cross-platform library, everything will work in Windows or Mac the same way.

[kpedersen]

So, how would you compile a program for the Raspian, from OpenBSD?
Thats where dependency management comes in, ideally you DL a source package on *any* platform and can compile for *any* target and dont inadvertently use mismatched headers/libraries from the host.

If I had an appropriate cross compiler (Clang is close), then I would extract the includes and libs from the Raspbian armv6 packages and link against them in a fairly ad-hoc manner ensuring to keep dependencies as low as possible (unlike a typical Rust Cargo project) to avoid the faff as much as possible.
For Emscripten, it is much simpler I would compile them up myself (because there are only a few). So quite a different solution to Raspbian.

build2 can only attempt the latter (like I said, it can't possibly hope to support all the many different Linux package managers) and it can also not provide me with a correct cross compiler. So it also cannot provide a solution to this problem.

I can imagine it is going to try to provide a massive central repository of all the different compiled libs and includes? Bit naff. Maybe a patch repository to help build on only the most common platforms. Again, a little naff.

[discordian]

If I had an appropriate cross compiler (Clang is close), then I would extract the includes and libs from the Raspbian armv6 packages and link against them in a fairly ad-hoc manner ensuring to keep dependencies as low as possible (unlike a typical Rust Cargo project) to avoid the faff as much as possible.
For Emscripten, it is much simpler I would compile them up myself (because there are only a few). So quite a different solution to Raspbian.

A dependency manager does that work for you. If you don't need dependencies thats of course of little value to you, if you start needed dependencies of dependencies you are quickly seeing the benefits.
Change the requested version of one dependency, and it will trickle up and pick compatible versions everwhere.

build2 can only attempt the latter (like I said, it can't possibly hope to support all the many different Linux package managers) and it can also not provide me with a correct cross compiler. So it also cannot provide a solution to this problem.

Crosscompiler is not part of the equation (can be, but its bloody hard to do), and I guess fetching dependencies via apt is not either. What it does is preparing a directory of header and libs (and to an extend build-tools).
what it can do is finding installed host-packages, but you dont need to know how it got installed for doing that,

I can imagine it is going to try to provide a massive central repository of all the different compiled libs and includes? Bit naff. Maybe a patch repository to help build on only the most common platforms. Again, a little naff.

Well, https://conan.io/center/ has 160k binary packages, and with conan there is also a source-package. Means either it can fetch the compiled library, or it can fetch its source and dependencies and build the lib locally. Then it also allows you to use local caches and local servers. So if your product has a battle-tested version with special-sauce compiler flags, it can use that prepared binary always, on multiple computers and multiple projects.

Note that I am talking about conan, I looked at build2 some time ago. While I find the build-system interesting and unique, I cant see the package manager gaining any traction if you have competitors that have an insane amount of packages already.

[pal666]

Why reinvent Meson, just differently?

you could ask why meson reinvented cmake

Edit, for those that may not know:

Meson has package management too!

ok, now it's clear that you don't know: meson is meta build system for generating build system files, build2 is complete build system

[pal666]

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

and what is the cross-platform systems native no-root-required package manager of your choice?

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

just like make requirement killed c? rust has no chance to replace c++ because it has no compatibility with c++

[pal666]

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.

you depend on 3 tools: python, meson and real build system(likely ninja). neither of which was born established and accepted. neither of which comes with windows btw. and their sum is less capable than one build2.

[pal666]

If I had an appropriate cross compiler (Clang is close), then I would extract the includes and libs from the Raspbian armv6 packages and link against them in a fairly ad-hoc manner

i.e. you would replace package manager with your hands? what's next? you don't need toolchain because you could type binaries in hex editor?

[computerquip]

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!

I wouldn't try to take technical discussion on Phoronix too seriously.

[computerquip]

The biggest problem with these projects is that they need more support and some sort of integration protocol.

Unfortunately, this project will run into the same. Every C and C++ project has their own favorite build system. Unfortunately, some of them aren't very friendly to work with such as practically every autoconf-based project, OpenSSL/Botan which use custom perl/python scripts instead of an off-the-shelf build system, and some others you don't hear of often like premake or RocketBuild. None of these are easy to integrate with without cutting some corners.

As such, I've become less concerned with the power of the build system I use, and more concerned with its ability to integrate with projects surrounding it, like the common OpenSSL.

Build2 doesn't fix that problem. That's also a bit of a community problem. Somehow, despite having a ridiculously saturated market for C/C++ build systems, we somehow still end up with projects that would prefer making a several-thousand line hardly-maintainable perl script that only the author can actually understand.

For those mentioning Conan... Conan is nice but it has some big names missing like qt, gtk, some boost variants, glib, and so on. The big names that are on there do not compile as easily as you think if you need something that isn't provided in binary form. That's the exact reason I don't use Conan. Almost none of the packages have first-party support.

[boris-kolpackov]

[...] OpenSSL/Botan which use custom perl/python scripts instead of an off-the-shelf build system, and some others you don't hear of often like premake or RocketBuild. None of these are easy to integrate with without cutting some corners.

Build2 doesn't fix that problem. That's also a bit of a community problem.

You are clearly aware of the real pain points. FWIW, we did convert OpenSSL to build2 but not without cutting some corners, at least for the time being (we are only using C, no assembler). It is a bit slower but it builds and works the same everywhere (we currently have it building in 57 different configurations).

On the bigger issue of it being the community problem, yes, it's true, but folks at OpenSSL didn't decide to require Perl for no reason. They needed to generate custom assembler depending on the configuration and none of the build systems were capable of that in a portable way. In fact, even now I don't think there is a build system capable of that (including on Windows) without any external dependencies (Perl, MSYS, etc), probably not even build2, yet (unless one ports this Perl code to C++). But that's our goal.