Skip to content

Conversation

@juergbi
Copy link
Contributor

@juergbi juergbi commented Nov 21, 2025

Duplicate dependencies are normally merged already in extract_depends_from_node(). However, that only works for dependencies that are declared with the same filename. If a link element is in a dependency list, merging may still be required but can be done only after the link element has been loaded.

The element state updates don't work correctly if there are duplicate dependencies that aren't merged.

Merging Dependency objects does not adjust the name or path. This means that if an element has duplicate dependencies, the name from the first dependency declaration is used. One could argue that we should always use the name of the link target, however, this would break cache keys (via configure_dependencies()) and I can't think of a real problem with the current approach.

Fixes #2002.

Duplicate dependencies are normally merged already in
`extract_depends_from_node()`. However, that only works for dependencies
that are declared with the same filename. If a link element is in a
dependency list, merging may still be required but can be done only
after the link element has been loaded.

The element state updates don't work correctly if there are duplicate
dependencies that aren't merged.

Fixes #2002.
@gtristan
Copy link
Contributor

gtristan commented Nov 21, 2025

Will #2002 occur only if there are 2 link elements with the same target declared in the same project ?

I'm concerned that we are seeing issues with a toplevel project link to a sub-sub-project element, and a (differently named ?) link from a sub-project to the same sub-sub-project element.

EDIT: If we have the cross project issue, we can treat that as a separate issue, but it would be good to have clarity and an open issue.

@juergbi
Copy link
Contributor Author

juergbi commented Nov 21, 2025

Will #2002 occur only if there are 2 link elements with the same target declared in the same project ?

This is about an element having multiple direct dependencies that resolve to the same element. Either multiple links with the same target or a non-link dependency + a link that points to that non-link dependency.

Projects/junctions are not relevant for this issue, as far as I can tell. I can't completely rule out that there is another link element issue in combination with junctions, but I'm not aware of such an issue.

@harrysarson
Copy link
Contributor

I tested this branch on the real-world project that was hitting #2002 and this has fixed the "element never builds, cannot artifact checkout" issues.

I have had a read through the patches and they look sensible to me!

Copy link
Contributor

@gtristan gtristan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM :)

@juergbi juergbi merged commit 12b11f8 into master Nov 26, 2025
49 of 90 checks passed
@juergbi juergbi deleted the jbilleter/links branch November 26, 2025 11:55
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.

BuildStream fails to build if there are multiple link dependencies with same target

3 participants