The generated header's path now depends on in-tree vs relocated builds
(database/database.h vs include/database/database.h), so instructions
that named it directly ("make database/database.h") are brittle.
Add a stable, path-independent top-level target:
.PHONY: prepare
prepare: ${DATABASE_H}
Being .PHONY the name is always valid, but its prerequisite is the real
file target ${DATABASE_H}, so the header is still regenerated only when
out of date -- same result, no exposed path.
Convert every "make database/database.h" in the docs, appimage
Dockerfiles, and CI workflows to "make prepare".
Verified: relocated `make prepare` generates include/database/database.h;
re-running is a no-op; touching database.h.in triggers regeneration.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The AppImage builders already shipped the pre-built PostScript
documentation (each Dockerfile runs "make install", and INSTALL_CAD_DIRS
includes doc/), but they did not install latex/dvips, so the docs were
never regenerated from source.
Install texlive (latex + dvips + recommended fonts) before the magic
build in all four EL variants (yum on EL7, dnf on EL8/9/10), so configure
reports "LaTeX docs: yes" and the default "make" regenerates the docs
into the build before "make install" ships them.
The install is non-fatal (|| echo): if a texlive package is unavailable
on a given EL release it falls back to the pre-built PostScript, so the
release image build can never be broken by documentation, and docs are
shipped either way.
NOTE: not build-tested here (no Docker/EL toolchain available). The
package names (texlive-latex, texlive-dvips,
texlive-collection-fontsrecommended) should be validated on each EL
image; the non-fatal guard protects the tag-triggered release builds in
the meantime.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Darryl L. Miles