Incremental

[aDotInTheVoid]

Options

1. Delegate to ninja somehow
   • This means spliting the binary into one part that generates ninja, and another that is called by ninja
   • Kinda like cmake (I wounder if meson does this)
   • Also probably with detection for when ninja is out of date
2. Reimplement some of ninja
3. Use a incremental library like salsa

[aDotInTheVoid]

Yep meson does

ninja: Entering directory `builddir'
[0/1] Regenerating build files.
The Meson build system
Version: 0.55.3
Source dir: /tmp/meson
Build dir: /tmp/meson/builddir
Build type: native build
Project name: tutorial
Project version: undefined
C compiler for the host machine: cc (gcc 10.2.1 "cc (GCC) 10.2.1 20201125 (Red Hat 10.2.1-9)")
C linker for the host machine: cc ld.bfd 2.35-15
Host machine cpu family: x86_64
Host machine cpu: x86_64
Found pkg-config: /usr/bin/pkg-config (1.7.3)
Run-time dependency gtk+-3.0 found: YES 3.24.24
Build targets in project: 1

Found ninja-1.10.1 at /usr/bin/ninja
[2/2] Linking target demo

[aDotInTheVoid]

Literature Review

• Hugo doesn't do this
• Jekyll does this, but it's knarly

  Under the current implementation, incremental regeneration will only generate a document or page if either it, or one of its dependencies, is modified. Currently, the only types of dependencies tracked are includes (using the {% include %} tag) and layouts. This means that plain references to other documents (for example, the common case of iterating over site.posts in a post listings page) will not be detected as a dependency.

• Gatsby claims to have solved this, but it's only in the cLoUd OfFeRInG

  This happens automatically with no configuration, with any data source, due to Gatsby’s sophisticated data engine powered by GraphQL. Gatsby’s data engine automatically tracks dependencies between pages and data, and—when data changes—schedules the minimum amount of work needed to update the site.

• Zola does't do this
• Amos says futile does this, but I dont know exacly how it works

  From the start, I wanted to allow incremental builds. The next time around, for each file we crawl and hash, we check if it's already in the DB. If it is, great! If not, we insert it. Because the templating is SQL and every page can access the entire DB, I dont know how much of this is correct, as it feels like this could go the jekyll route of not doing it "fully"

[aDotInTheVoid]

https://aosabook.org/en/500L/contingent-a-fully-dynamic-build-system.html

[aDotInTheVoid]

https://codeberg.org/adot/xmark

[aDotInTheVoid]

Closing, the codeberg version has this