Ladybird browser spreads its wings

==> How Chromium Will Support the Use of Rust

https://security.googleblog.com/2023/01/supporting-use-of...

The README says it is extensible "to support new languages and custom rule sets." I wonder if it can be extended for C++ modules? Then setting up a C++ project (that uses modules) in Bazel should be much easier.

There are 2 plausible strategies AFAIK ("explicit" and "implicit"). I consider only 1 ("explicit") viable in the grand scheme of the state of the C++ ecosystem where even file extensions cannot be agreed upon. There are tradeoffs of each. For CMake, I chose the one that gives the most reliable results with the widest support because I detest tracking down heisenbuild bugs and CMake ends up having to support all kinds of things anyways.

> some tool parses the module files and generates module description information, which can then be considered by the build system, which can then be considered by the build system, which I think is the way CMake has gone (it's good for them because they already have a separate "configure the build" step).

This is inaccurate. CMake does this during the build, not during "configure". If it were done during the configure step, any change to a C++ module-using or -providing source would require a rerun of the configure to update the build graph. Note that it must also be performed at build time in order to support generated sources (that don't exist to scan at configure time). This is obviously not optimal.

Some definitions (for clarity):

- build system: a model of a project that represents artifacts and the dependencies between them (e.g., CMake, Bazel, Meson)
- build tool: a tool which executes a DAG representing a build system's actions to perform the necessary (e.g., Bazel, make, ninja)
- BMI: "binary module interface"; a representation of a module interface that is used when importing the module
- CMI: "compiled module interface"; same as BMI; preferred by some because they might not be "binary", but ASCII
- module interface unit: a source file with `export module X;` or `[export] module X:partition;`; may be imported (assuming language and build system visibility rules allow it)
- module implementation unit: a source file with `module X;` that provides implementations for module interfaces that have `module X` (with or without a partition name; implementation units never mention partitions[0])
- explicit module build: the compiler is told the exact BMI file to use for each module it reads or writes
- implicit module build: the compiler is given search paths to look for or to create BMIs by name (note that this includes when a build system just uses the module name as a key to look them up rather than considering the context of the importing source file: is the requested module visible? is it the right configuration?)

For background, this paper[1] I presented to ISO C++ which describes how CMake supports Fortran modules (which are isomorphic to C++ modules for build graph purposes). The core issue is that the module name has no (forced) relation to the filename on disk. So one needs to determine the dependencies between compilations *dynamically*. This is distinct from "discovered" dependencies reported by the likes of `-showIncludes` or `-MF` where the files that are discovered during the course of the tool's execution are reported so that if any change, the tool can be reexecuted. The main point here is that they can be discovered during the first execution (since the output doesn't exist, it needs to run anyways). Modules are different because at the point of `import M;` during translation we need the BMI of M to continue compilation as the next line might use a type from that module. The compiler needs to know where that BMI is and is the primary goal of the build system for modules: to provide BMI paths during compilation and ensure they're ready when compiling anything that needs them.

Dynamic dependencies instead are dependencies between entities expressed in the *content* of the sources and nowhere else. To support this, the contents need to be "scanned" to report what is needed during compilation and generated during the compilation of the source itself. This is reported in the P1689R5[2] format that is meant to describe these things. These dependency files (CMake uses the `.ddi` extension: "dynamic dependency information") are then given to a "collator" that reads them, the collated information of any dependent libraries, and some details from the CMake, to do the following:

- see file X makes module P
- sees file Y needs module P
- writes out a snippet for the build tool (ninja, make) to learn that Y's object rule depends on X's object rule (this is what the details from CMake are needed for: the collator needs to know the paths ninja knows these things by to make a valid dyndep file)
- writes out a representation of this information for any dependent libraries so that they may be consumed in other targets as well
- writes out a "modmap" file for each TU saying "I see you want modules E, F, G; here is the path for those modules *and no others*" (this is important to avoid accidental/stale module usage; note that Fortran doesn't have this because module files are found via `-I` flags implicitly…I uncovered a lot of issues with that when enforcing C++ strictness on the Fortran stuff in CMake)
- (there are some other tasks[3], but they're not relevant to the build graph)

There is some flexibility with this model (also covered in the paper):

- scan individually or scan in batches?
- collate separately or after scanning?

Smaller scans are better for incremental (developer) builds (e.g., if 20 files are scanned in a batch, changing any one will force scanning of all 20); batching is better for one-shot (CI) builds. Collating after scanning simplifies the tool (the collator doesn't need to understand $LANG syntax), but is probably slower (lots of tiny P1689 files flitting about). CMake currently has individual scans with separate collation. I don't forsee collation being merged into scanning, but an option to batch scans may make sense given performance measurements.

Restrictions can also be enforced here. CMake doesn't care about file extensions, basenames matching module names, or anything like that. If one wants to do that (I suspect Meson might do so), that's fine. Configure-time scanning is fine if the configure is fast enough and generated sources (module-providing sources for sure; module-consuming sources may be able to be deferred-scanned, but once you have that support…just simpler to scan everything at build time if you ask me) aren't of any concern.

> There was also an idea of using an LSP-like model, where a separate server process would keep the module dependency information and respond to requests from clients at runtime.

This is, AFAIK, what build2 does (it is a build system and a build tool). It may implement it to the level of being an "explicit" build, but I've not dug in to know. There are patches to GNU Make to act as a module mapper as well. This patch only works with GCC today; Clang may add support for libcody in the future. Any "implicit" implementation has a major flaw in the generic case: I don't know how to meaningfully give visibility to modules. Note that the "`-fmodule-directory=` Clang flag where Clang just reads and writes files in the given directory based on module names as this strategy as well (the filesystem is the "module mapper" here).

I find this to be problematic in practice because it means the state of the build graph depends on the runtime state of some running process, not just mtimes, content fingerprints (for tools which are hash-the-content-based rather than mtime-based), some metadata on disk (e.g., `.ninja_log`). I can't imagine how debugging this is expected to work when those not well-versed in build systems are on the front lines.

Beyond that, there are corner cases to consider:

- When a request to import module Q comes in, how many processes do we expect to launch before we find the rule that exports module Q is found? What if it lies beyond our `-j` limit? Do we suspend processes while we wait, doing job server shenanigans? What if it doesn't exist? What if we discover a module import cycle?
- The LSP-model must have some concept of module visibility in mind. Library L links to library K; K's sources should not be able to import any modules that are part of L. Even within L, if a module is not "public", it shouldn't be importable from outside of the library (including transitively by its own module interface files).
- With the filesystem-as-mapper model, stale files are a serious issue. If I rename module R to S, what is in charge of cleaning up R's BMI file? How do I say "yes, you found it; it is radioactive"? What remembers that the now-scanned S creator used to make R to clean it up?
- Duplicate module names. While C++ forbids multiple named modules within a program, nothing prevents `export module test;` from appearing in separate binaries. Related: if the build graph has release and debug variants, one now needs to track the debug version of module M separately from the release version.

These are not easy questions to answer and that's on top of two-way communication with compilers you're launching.

[0] There is a wholly unnecessary MSVC extension where it is allowed (IIUC, due to a misreading of the standard that, TBF, we also had when starting CMake's implementation); easily avoided and made portable: drop the partition name.
[1] https://mathstuf.fedorapeople.org/fortran-modules/fortran...
[2] https://wg21.link/p1689r5
[3] Namely writing install rules for the BMI files and CMake properties for exported targets.

You're free to provide actual counterexamples of worthwhile projects that don't have more feature complete non-Rust alternatives. The fact of the matter is, once you wade through the Rust rewrite announcements, there is little more than an academic exercise afoot. And there's nothing wrong with that, but "delusional" is pretending that there is a real purpose beyond marketing, ego-stroking, or some combination there within. Rust, just like the crypto-scamming boondoggles it was previously associated with, is perennially a solution in search of a problem. Languages like Go, Zig, and yes, even C++ have proven to be more suitable and reasonable languages for when real work needs to be done and marketing fails to suffice. I'm all ears for counterexamples.

> A user asked on June 6 what would determine whether a component would be developed in-house versus using a third-party library. Kling responded that if it implements a web standard, "i.e DOM, HTML, JavaScript, CSS, Wasm, etc. then we build it in house."

As a developer familiar with multimedia streaming, I would say even re-implementing WebRTC alone will be a huge challenge for the small team.

Seriously, calling Firefox a dying platform will not add one's own value, it just pisses out faithful users of Firefox (there are a LOT here on LWN).

But I remember being pretty handy with alt-shift-F1 and alt-shift-backspace, or whatever the hotkeys were to get to the virtual consoles and hard-kill X.

And X dying was almost as bad as a full reboot for a desktop where apps didn't do a terribly good job with checkpoints and session restores.

So, while restarts and blue screens and corrupted data is what moved me off of Windows in the early 2000s, the Linux Desktop was not nearly as stable as it is today.

Nowadays, I had one desktop issue in the past few years, and I had System76 support figure out the issue and send me a new driver (which weirdly was triggered by using Google Maps in Firefox). Worlds better than when I was running a Mandrake (RPM) Frankenstein where half the software was compiled from tarballs because the RPMs available were woefully out of date..