Repository navigation
cmake: remove fprime-util metadata of the un-parented directories on configure - #277
devin-ai-integration[bot] wants to merge 3 commits into
Conversation
|
I'll fix CI failures and address comments from users with write access that start with 'Devin'.
Original prompt from thomas.boyer.chammard
|
…configure The fprime-util metadata files (build-targets, sub-directories, tests, test-dir .fprime-util) are appended to during configure and only cleared by the parent directory in add_fprime_subdirectory. The project root and the directory calling fprime_setup_included_code have no such parent, so every re-configure appended another copy of each entry and fprime-util build ran each listed target once per copy (repeated dictionary install). Remove those files once per configure: the root when FPrime.cmake is included, the include directory at the start of fprime_setup_included_code. Files are removed, not truncated, so a directory that registers nothing stays without files as fprime-util expects (a missing build-targets file selects the default target, an empty one selects nothing). Add cmake/test/src/test_metadata.py.
96d0977 to
22151d5
Compare
devin-ai-integration
Bot
changed the title
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
There was a problem hiding this comment.
🟡 Metadata accumulates in plain subdirectories
When a plain add_subdirectory registers F Prime targets, reconfiguration appends to its old metadata. Neither the parent nor fprime_setup_included_code clears that directory, so fprime-util repeats its targets.
Learn more
F Prime target registration appends a name to a per-directory metadata file. The usual add_fprime_subdirectory clears a child's metadata before entering it, while fprime_setup_included_code clears its own directory. An ordinary CMake add_subdirectory that registers an F Prime target has neither reset. On the next configure, the old file survives and registration appends its targets again; fprime_util_metadata_add_subdirectory only clears directories explicitly passed to it.
Example: A project enters extras using CMake's add_subdirectory(extras) and extras registers ExtraModule. The first configure writes ExtraModule; a second configure writes ExtraModule twice. Running fprime-util build from extras now invokes that target twice.
Recommended fix: Restore first-write clearing for directories not reset by a parent, without clearing root or framework metadata after earlier writes. Track directories cleared by fprime_util_metadata_clear and by the new early removal calls, then clear an untracked directory before its first append.
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
Known limitation, accepted by design: this change resets exactly the directories that have no add_fprime_subdirectory parent today — the project root and the directory that includes F´ (the only plain add_subdirectory in the framework/TestDeploymentsProject that registers F´ targets; googletest/ and STest/ register none). A project directory entered with plain add_subdirectory is already outside what fprime-util tracks (it is absent from the parent's sub-directories.fprime-util, so build -r never visits it), and add_fprime_subdirectory is the documented way to enter such directories. Covering arbitrary writers would need per-configure global state ("first writer clears"), which was deliberately traded away for the stateless explicit reset.
* clear top level metadata files so repeated builds don't add no-op targets * Remove, not truncate, un-parented fprime-util metadata (#6238) Truncating the project-root build-targets.fprime-util left an empty file where devel has none; fprime-util reads an empty file as "nothing to build", so building TestDeploymentsProject (find_package layout) became a no-op (CI: Ref "ninja: no work to do.", Integration Tests missing ref-build-artifacts). Remove the root metadata instead, and also reset the directory that includes F Prime in fprime_setup_included_code, which no add_fprime_subdirectory parent clears. Fix taken from JPL-Devin#277. Co-authored-by: Aaron Black <aaron.black@jpl.nasa.gov> Co-authored-by: Aaron Black <ablack@.jpl.nasa.gov> Co-authored-by: Thomas Boyer-Chammard <49786685+thomas-bc@users.noreply.github.com> Co-authored-by: M Starch <LeStarch@googlemail.com> --------- Co-authored-by: Aaron Black <ablack@.jpl.nasa.gov> Co-authored-by: Aaron Black <aaron.black@jpl.nasa.gov> Co-authored-by: Thomas Boyer-Chammard <49786685+thomas-bc@users.noreply.github.com> Co-authored-by: M Starch <LeStarch@googlemail.com>
|
Superseded by nasa#6277 (merged into devel), which carries this fix. |
Change Description
Add
fprime_util_metadata_remove(DIRECTORY)incmake/fprime-util.cmake(removes the four*.fprime-utilmetadata files of a directory) and call it once per configure for the two directories noadd_fprime_subdirectoryparent ever resets:CMAKE_BINARY_DIR), at file scope incmake/FPrime.cmakenext to the existingfprime-*-locationsresets;F-Prime/), as the first statement offprime_setup_included_code(), beforefprime_setup_platform()writesPlatformXxx/allinto it. Skipped when that directory is the root.Parented directories keep today's behavior (
fprime_util_metadata_clear, empty files). The root files are removed rather than truncated because fprime-util treats a missingbuild-targets.fprime-utilas "fall back to the default target" and an empty one as "nothing to build".Rationale
Metadata is written with
file(APPEND)and only cleared by the parent'sadd_fprime_subdirectory. The two directories above have no such parent, so every re-configure (ninja auto-rerun after aCMakeLists.txtedit, repeatedfprime-util generate, ...) appends anotherPlatformXxx/allpair and another copy of each deployment path.fprime-util buildthen runs each listed target once per copy:generate -fresets the cache, which is why it is intermittent. Not platform specific; reproduced natively withTestDeploymentsProject(after 7 configures,fprime-util build --recursiveranRef_dictionary7× on devel, 1× with this change).Testing/Review Recommendations
fprime-util generate, thencmake .in the build cache a few times:F-Prime/build-targets.fprime-utilstays at two lines (PlatformXxx,all), the rootbuild-targets.fprime-utilstays absent, andfprime-util buildruns each target once.Future Work
None.
Contributor Checklist
AI Usage (see policy)
Diagnosis and code written by an AI agent under engineer direction.
AGENTS.md).IAMAI