Re: [BuildStream] Allowing duplicate junctions [Was: Be explicit when overriding junction configuration, or else warn/error]

[Tristan Van Berkom <tristan vanberkom codethink co uk>]

Hi,

On Sat, 2020-06-06 at 12:51 +0200, Jürg Billeter wrote:
> Hi,
>
> On Fri, 2020-06-05 at 18:18 +0900, Tristan Van Berkom wrote:
> > [...]
> >
> > You are touching upon a flaw I've been thinking of since last night.
> >
> > It should not be possible for a project to mark *both* conflicting
> > projects as "duplicate", but only the ability to mark one project as a
> > duplicate of the other (or possibly multiple projects as a duplicate of
> > a single one).
> >
> > Perhaps this can be addressed by causing an error to occur if ever
> > duplicates are listed for all instances of a project, another approach
> > might be to change this semantic to use a dictionary instead of a list
> > (denoting which subproject junction is a duplicate of which, allowing a
> > bit more validation to catch this before hand).
>
> We also need to cover the (presumably rare) case where there are more
> than two junctions to the same project. If we want to be explicit and
> list both/all conflicting junctions, what about something like this?
>
>   duplicate:
>     project-foo:
>     - local-foo-junction.bst
>     - subproject.bst:sub-subproject-foo.bst
>     project-bar:
>     - local-bar-junction.bst
>     - ...
>
> I.e., have a list for each project where duplicate instances are
> allowed (except `internal`) and then require listing all these
> junctions.

I like this API better indeed.

With this approach, we can require that *all* instances of a project
that is duplicated, and at face value, it appears to be a much more
clear API because of this requirement (as opposed to requiring that one
instance of project be omitted from duplicate lists so as to reliably
report errors in reverse dependency projects).

That said; there is one problem with this approach, which is the
toplevel project.

In the case of a self-junction which is not internal, or a possibly
cyclic pattern of project dependency, we need a way to express the self
project in the duplicates list.

> When inheriting duplicate declarations from a subproject we would merge
> duplicate lists per project (prefixing the declarations from the
> subproject with the subproject's junction name, of course). This should
> allow declaring an extra duplicate in the top-level project without
> having to know about deeply nested junctions that have already been
> marked as duplicate by a subproject.

Right, that's pretty much the idea, however it is imperative that we
have a way to ensure that reverse dependency projects clash when adding
a new project (which is why originally I had thought of ensuring that
one instance of project always remains unduplicated for that purpose).

Still, it should be implementable.

Cheers,
    -Tristan