Skip to content

docs(build): stage English sources with per-file rules so one make rebuilds - #4358

Merged
BsAtHome merged 1 commit into
LinuxCNC:masterfrom
grandixximo:docs-rebuild-unstable
Aug 8, 2026
Merged

docs(build): stage English sources with per-file rules so one make rebuilds#4358
BsAtHome merged 1 commit into
LinuxCNC:masterfrom
grandixximo:docs-rebuild-unstable

Conversation

@grandixximo

Copy link
Copy Markdown
Contributor

Fixes #4354.

@BsAtHome I reproduced your recipe exactly: after a full HTML build, touch ../docs/src/config/python-interface.adoc then make re-stages the file but renders nothing, and only the run after that rebuilds the page.

The cause is mine, from c774b79. English sources are staged into docs/build/adoc/en by a bulk find|tar behind .stage-en-stamp, with the staged copies attached to it order-only:

$(DOC_OUT_ADOC)/en/%.adoc: | $(DOC_BUILD)/.stage-en-stamp ;

make stats a prerequisite once per run and re-stats it only if it decided to remake it. An order-only edge never triggers a remake, so that empty-recipe rule was never "remade" and the staged .adoc kept its pre-staging mtime for the whole run. The stamp recipe rewrote that same file mid-run, but the renderer had already compared the .html against the stale mtime and concluded it was up to date. The next make saw the fresh mtime and rendered.

Replacing the stamp with one copy rule per staged file makes the change visible to make, so the render fires in the same run. cp -p also keeps the source mtime to the nanosecond, where tar rounded it down to the whole second; that could leave a staged copy a fraction older than a .html rendered from it in the same second and lose the edit outright.

Per-file rules alone are not enough: they stage only what some rule asks for, which is a smaller set than the bulk copy produced. asciidoctor resolves include:: and image: against the staged tree at render time and most of those are not make prerequisites, so a partial like hal/halshow.adoc would never land and hal/tutorial.html would render an "Unresolved directive" placeholder instead of its content. A stage-en aggregate keeps the old guarantee.

Verified with HTML, PDF and the seven translations enabled: a clean build renders 5210 pages and 32 Master PDFs with no unresolved directives, the two builds after it do no work, and a touched source re-renders in a single make followed by a no-op.

Could you confirm this clears it on your machine?

One note for later: while tracking this down I found that docs/src/asciideps still strips a .txt suffix from when the docs were written in that format, so since the move to .adoc every rule it generates names a target nothing builds and the whole dependency extractor has been inert. Editing a chapter has not rebuilt the Master PDF that includes it. I have that fixed and verified on a follow-up branch, which I will open once this merges, since the two touch adjacent rules in the same file.

…builds

Fixes LinuxCNC#4354.  After a full HTML docs build, touching a source under docs/src did nothing on the next `make`; only the run after that re-rendered the page.

English sources are staged into docs/build/adoc/en by a bulk find|tar behind `.stage-en-stamp`, with the staged copies attached to it order-only.  make stats a prerequisite once per run and re-stats it only if it decided to remake it, and an order-only edge never triggers a remake, so the staged .adoc kept its pre-staging mtime for the whole run.  The stamp rewrote that same file mid-run, but the renderer had already compared the .html against the stale mtime and concluded it was up to date.

Replace the stamp with one copy rule per staged file, so make knows the staged copy changed.  cp -p also keeps the source mtime to the nanosecond where tar rounded it down to the whole second.  Per-file rules alone would stage only what some rule asks for, which is a smaller set than the bulk copy produced, so a `stage-en` aggregate keeps the old guarantee that everything lands before anything renders; without it a partial like hal/halshow.adoc never arrives and the page including it renders an "Unresolved directive" placeholder.
@BsAtHome

BsAtHome commented Aug 8, 2026

Copy link
Copy Markdown
Contributor

Works as expected. 👍

@BsAtHome
BsAtHome merged commit c794fcc into LinuxCNC:master Aug 8, 2026
16 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Doc html re-build unstable

2 participants