libraries: track submodule fetch via its .git entry, not a stamp file#4439
Open
d-torrance wants to merge 1 commit into
Open
libraries: track submodule fetch via its .git entry, not a stamp file#4439d-torrance wants to merge 1 commit into
d-torrance wants to merge 1 commit into
Conversation
If a SUBMODULE = true library was fetched and then the submodule was deinitialized (e.g. via git submodule deinit), the old .submodule-updated stamp file would remain, causing the build to fail since the submodule directory is empty. Instead of a separate stamp file, make fetch depend directly on submodules/$(LIBNAME)/.git, which is created by update-submodule and removed by deinit. This makes the dependency self-correcting: if the submodule is deinitialized (or never initialized), make reruns update-submodule; if it's already present, fetch is a no-op. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
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.
This should fix an issue identified by @joel-dodge in Zulip. Let's say we want to use the autotools build to to build some dependency for which we use a submodule instead of a tarball (say, memtailor). First time around, no problem.
Now let's say we're sick of submodule changes showing up in our
git statusso we decide to deinitalize them. But that doesn't remove the.submodule-updatedstamp file that the autotools build writes when it updates a submodule. So the next time we go to build that dependency, the build fails because we think we don't need to update the submodule again.Before
Here's an example of the failing behavior with memtailor:
After
Now instead of using the
.submodule-updatedstamp file, we just check for the existence of the.gitfile in the submodule. It gets removed when we deinitialize, so we know it's time to initialize again.AI Disclosure
Claude wrote the code with significant hand-holding.
Here's its commit message: