boris

6 pages of gaming benchmarks and not one compilation speed test. Baffling.

That's a double-edged sword: because make doesn't "support" your language things get hairy (think sed) as soon as you need to support anything non-trivial (say header dependency extraction for C/C++). Doing it in a portable way is often just impossible (try to do header dependency extraction for MSVC on Windows with make).

So ideally you want both ad hoc rules (like make) as well as some king of build system plugin support which allows you to write more complex rules in something more powerful and portable. This is the approach we have taken with build2[1].

[1] https://build2.org

With the introduction of modules in C++20 there is now an intriguing possibility of implementing a new/cleaned-up language with compatible object model/ABI and using modules to interface with existing C++ and even C (via header units).

This ("the conceptual model is sound but the implementation could be improved") is pretty much the basis for build2: https://build2.org/build2/doc/build2-build-system-manual.xht...

make works well when you are targeting a single platform with a decent shell and the project is not too complex (e.g., no auto-generated source code that requires its own automatic dependency tracking). Once that no longer holds, make becomes a real liability.

This looks promising (even at $750 for the motherboard and CPU) but it seems to be a work in progress, specifically at the bottom of the page it says:

    Mainline Kernel – work in progress
    UBoot – work in progress
    UEFI – work in progress

But if anyone has any experience using this board, please share.

Slightly off-topic: is there anything that is as or more powerful than RPi4 but has more/expandable memory (say 16G or more) and still works with mainline kernel/distributions? In other words, something that I could setup as a build machine for CI?

Anyone hopping to have ECC with Ryzen should really read the reddit thread. Wow, what a mess.

Funny you asked, build2[1] can be (and is[2]) used to package bash. It even has build system support for modularization of bash scrips[3].

[1] https://build2.org

[2] https://cppget.org/?packages=bash

[3] https://build2.org/build2/doc/build2-build-system-manual.xht...

See my reply to a sibling comment.

Yes, we need to change that. Our initial focus was on taking really good care of C/C++ compilation but now we are at the stage (i.e., we have support for external build system modules) where this is starting to change.

"Works" can mean very different things on Windows. On one extreme you can have proper integration that covers Windows' idiosyncrasies such as automatically finding and setting up the Visual Studio environment instead of making the user jump through hoops like starting the dev command prompt. And on the other extreme you can have something hacky like "requires Cygwin" which I personally wouldn't even call "works".

On the contrary, build2 is a language-agnostic, general-purpose build system. There is the bash module[1], for example. And now that we have support for dynamically buildable/loadable build system modules, we can develop support for more languages, code generators, etc., without bundling it with the build system core. I myself am itching to take a stab at Rust. Hopefully will find time after the release.

[1] https://build2.org/build2/doc/build2-build-system-manual.xht...

I wonder if they considered build2[1]? It seems to tick most of their boxes. In particular, it has first-class Windows support and, in the upcoming release, even native Clang-targeting-MSVC support (not the clang-cl wrapper)[2]. While some of the features they are looking for (like faster build times which I assume means distributed compilation and caching) are not there yet, we are working on them (and would welcome help)[3].

[1] https://build2.org

[2] https://stage.build2.org/?builds=&cf=windows_10-clang*

[3] https://github.com/build2/README/blob/master/roadmap.md

Their diagnostics is pretty cool, though. How about this gem:

  ld: warning: ignoring file build2/libb.u.a, building for macOS-x86_64 but attempting to link with file built for unknown-unsupported file format

Going to steal that "unknown-unsupported" term for sure.

You probably mean 9.0.0, 4 is several years old. Or is Rust really still using something pre-4?

Not yet, but it's coming. And most of the really difficult infrastructure is already there, at least for the C/C++ compilation.

There are alternatives that satisfy this (valid, IMO) requirement. For example, there is build2 (https://build2.org ; full disclousure: I am involved with the project) that tries to achieve the same objectives (correct & fast builds, uniform interface accross platforms, being language agnostic, etc) though not necessarily using the same mechanisms (build2, for example, tries to be fairly light-weight). Here is the introduction if anyone is interested: https://build2.org/build2/doc/build2-build-system-manual.xht...

It does but not in a way you probably expect it to be handled: i.e., with some filesystem mechanisms to make the update command only see what has been declared as target's dependencies -- I must admit I don't know Bazel does this in a cross-platform manner (Windows, Mac OS); copying seems way too heavy-handed.

In any case, in build2 this is "handled" by not including headers as "foo.h" but as <libfoo/foo.h>, that is, with the project prefix. You can read more on this here: https://build2.org/build2-toolchain/doc/build2-toolchain-int... And the proper fix will hopefully come with C++20 modules.

The OP was vague on why exactly hermetic builds are required to achieve fast builds. The only concrete thing they mentioned is caching which doesn't require hermetic builds (in the strict sense, as in preventing any outside changes) provided you can detect changes accurately.

To give a specific example, Bazel may prevent you from accidentally using a different version of the compiler while build2 will detect that you are attempting to use a different version.

I never said build2 is "in the same spirit" as Bazel (whatever that means). I said it fixes the same problems as OP listed.

It currently doesn't do fully hermetic configurations (as in, where it is impossible for any inputs to come outside of the project). Instead build2 does high-fidelity builds where it makes sure that if any of the inputs change (including options, environment, compiler itself, etc), the target gets rebuilt. See my reply to a sibling comment for some details. We do plan to add support for hermetic builds though it won't be exactly like Bazel's -- the idea is to prevent and, where not possible, detect external changes and fail rather than rebuilding.

Regarding caching (and distributed compilation), this is currently on the TODO list though a lot of the infrastructure is already there. For example, the same change detection that is used for high-fidelity builds will be used to decide if what's in the cache is usable in any particular build.

While I agree we should mention these points in the documentation (things are still WIP on that front), I don't think cross-compilation deserves mentioning: for any modern build system it should just work. In build2 we simply implement things in the "cross-compile first" way, with native compilation being a special case (host == target).

It doesn't do Bazel's style sandboxing where your entire compiler toolchain is part of your build system. It does what we call high-fidelity builds: it tracks changes not only to inputs but also to compile options, compiler itself (checksum), environment, etc., and if any of these auxiliary dependencies change, it triggers a rebuild. There are advantages and disadvantages to both approaches with build2's being lighter weight.

Bazel (and Bazel-derivatives/alikes) is not unique in fixing all of these problems. For example, there is build2, which is arguably a lighter-weight and closer to make (in spirit, not in syntax) solution (no Java dependency, etc). Here is an intro, if anyone is interested: https://build2.org/build2/doc/build2-build-system-manual.xht...

I would look into pcengines. It has everything you have described (or a port to plug it to) except for the battery. This is my go-to device for anything specialized (router, backup).

Yeah, also, according to the article, AMD has been aware of the issue for some time now. Buy it seems there is no urgency to address this.

If you are wondering why would someone prefer slower/insecure/etc processors from Intel, this would be a good reason; I want to get on with my work rather than debug AMD's processors for them.

We are making a Cargo-like build toolchain for C/C++, if anyone is interested: https://build2.org

Yes, thread-sanitized code is unbearably slow. Plus, you cannot use both ASAN and TSAN in the same build (but either can be combined with UBSAN).

This comes down to the cost of failure. If your app crashes or hangs sometimes, some of us might get annoyed but in the end we are all used to this now. It's a different story if your engine blows up from time to time. I am sure if every failure meant a 6 month and a million dollars setback, we would be designing software differently.

What hardware do you use for development and for testing? Can you elaborate on your setup, ARM-wise?