Maynard Handley (name99.delete@this.name99.org) on November 26, 2020 1:02 pm wrote:
>
> Of course building is a different type of task from a standard file system! In particular building generates
> a large number of blobs which are essentially ephemeral and do not need the strong promises of persistence
> provided by the file system.

Yes they do need certain guarantees. Including persistence and integrity. You need the intermediate files to be able to perform incremental builds. You need to be sure they are not corrupted e.g. due to the underlying media failure when you (re)use them.

And I fail to see how a database solution would not be persistent. Keeping all the intermediate data in RAM is simply not realistic even for moderate sized projects.

> But if you insist on using only the APIs of the ancients, then there is no way
> to express this ephemerality; the best you can do is fake it via a deliberately ephemeral (bespoke) file
> system like a RAM disk, or you can optimize the rest of the file system for this ephemeral task, at the expense
> of robust persistence. (Clearly a tradeoff that almost none on the Linux side understand, to judge by the
> sheer idiocy and cluelessness of the comments following when I explained this a week ago.)

A hint to the filesystem might be useful, although exactly how much benefit it would provide is not clear. Even if it does, that hardly requires a completely new approach to filesystems.

> And of course a whole lot more comes along if you build into a database rather than misusing the file system,
> in particular dependency can be more reliable than the shaky chain of "last changed" dates and guessed-at dependencies
> that comprise make.

I'm not sure what's your point here. Whatever the underlying storage, a build system has to track dependencies and rebuild targets as necessary. This works with current filesystems just fine, and I'm sure it could be made to work with a database. I don't see it as a reason to choose one solution over the other.

> You can persist modules or headers or various compiler-internal graphs in the most convenient
> form rather than forcing them down to a serialization that's slow to load into and out of the compiler or linker.

If you think you could just dump compiler memory to a database then you are mistaken. Serialization happens one way or the other.

> You can query the database for certain code patterns in ways more sophisticated than grep.

Compilers do not use grep. They actually don't work with text beyond parsing the source code. There is C/C++ preprocessor, but it already works with tokens. The bulk of the work happens on expression trees, which are not even the source programming language anymore.