build2 VS cw

Yes, this is a common stumbling block for users with the CMake background. The underlying reason is that build2 is a "multi-repo first" build system while CMake is "mono-repo first" (or perhaps even "mono-repo only"; I don't think there were repositories as we know them when Autotools was designed ;-)). In particular, in build2 it's common to build multiple independent projects/repositories in a shared build configuration. Putting this build configuration as a subdirectory of source directory of one of them would be strange. You can read more on this in this issue: https://github.com/build2/build2/issues/187

build2 can generate Clang compilation database (currently indirectly): https://github.com/build2/build2/issues/96 I believe quite a few IDEs (including CLion) can work off that.

Yes, please, that would be very helpful: https://github.com/build2/build2/issues

For things that are commonly and almost-ideally represented as text files, there’s a lot of Rust based alternatives are faster and have more features than the old unix/GNU tools: ripgrep, fd, cw, and you can find more in this list.

Nice, beats my old Rust wc through sheer brute force on my old 12c/24t server:

A lot of unix-y tools have been rewritten in rust, where the usefulness comes from it being faster or having more features. Examples: bat, cw, lsd, ripgrep, diskonaut, gping. Maybe you could find an interesting program to rewrite?

cw, an optionally-multithreaded bytecount-accelerated wc clone

Having written a Rust wc implementation a few years ago (https://github.com/Freaky/cw), I had a look at theirs.

It's pretty naive - a simple linewise read_until loop, a conditional to avoid word splitting and such if it's not needed, and for some reason it collects results into an array and prints when it's done rather than printing as it goes.

It doesn't support --files0-from like GNU wc, so isn't a drop-in replacement from that perspective. It also has the sadly common Rust trope of only supporting filenames that are valid UTF-8.

It doesn't seem overly slow considering its simplicity - usually trading blows with GNU and BSD wc. Perhaps the most glaring omission is the lack of a fast path for -c, which should reduce to a stat() call. Also unfortunate not to use the excellent bytecount crate to provide a very fast -l/m path.

The read_until loop also makes its memory use unpredictable compared with other wc's. If you run it on /dev/zero it will try to eat your computer.