CMake: Fix stale staging of headers, modules list, and temporal SQL in build output#7720
Merged
Merged
Conversation
nilason
approved these changes
Jul 15, 2026
nilason
left a comment
Contributor
There was a problem hiding this comment.
Thanks, in particular the header files have bothered me for a while, but I always kicked that can further down the road.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
These were identified problems by AI during unrelated work, below is the AI explanation. Probably not high priority, but could be useful.
This PR fixes three CMake staging defects that leave the runnable tree under
build/outputstale or incomplete, typically after editing headers or switching branches. Each showed up as confusing failures unrelated tothe change under test.
What changed:
Staged headers now refresh. The copy command in
include/CMakeLists.txthad noDEPENDS, so once a header was staged it was never re-copied. Editing a header (e.g.include/grass/gis.h) caused compilation against the stale copy andGIS_H_VERSIONmismatch fatal errors at runtime.Stale modules no longer linger in
ALL_MODULES. Modules append themselves tomodules_listasCACHE INTERNAL, but the top-levelset(modules_list)only cleared the normal variable, so the cached list accumulated across configures. After switching to a branch where a module no longer exists, builds failed with "No rule to make target". The cache entry is now reset at the start of each configure, before any module registers, which keeps the previous membership (including the helper programs fromlib/andutils/) while dropping stale entries.Temporal SQL templates are staged.
lib/temporal/SQL/*.sqlwere install-only, so temporal database creation failed when running frombuild/outputbeforecmake --install. They are now copied next to the library, following thelib/gisetc-file staging pattern. As with that pattern, the copy runs when the library relinks, not when only a.sqlfile changes.Verification:
gis.hand buildingINCLUDE_HEADERSre-runs the copy.modules_listdisappears on reconfigure, and the pre-existing helper program entries are kept.etc/sql, rebuildinggrass_temporalstages all 30.sqlfiles (and only those, not the Makefile in the same directory).AI disclosure: implemented and verified by Claude (Fable).