Re: [BuildStream] How to synchronize nested junctions

[Chandan Singh <chandan chandansingh net>]

Hi Jürg,

On Wed, Apr 10, 2019 at 7:41 PM Jürg Billeter <j bitron ch> wrote:
> I was rather expecting the 'pseudo' junction not to have any sources
> but rely on another junction for [core-libs]. Otherwise you'd need to
> synchronize the [core-libs] ref in core-libs.bst and base-sdk.bst
> (would be in the same project but still).
>
> Also, where would you specify options for the [core-libs] subproject?
> junctions/base-sdk.bst in [core-libs] might have conditionals or
> variables that are controlled by [core-libs] project options. They
> would probably also have to specified in the junction file above but
> that could be confusing.
>
> Do you see an issue with skipping sources and specifying something like
> 'core-libs.bst:junctions/base-sdk.bst' in the above junction file as
> target instead?

I was thinking about this. The reason I originally didn't go with this
approach was because I thought it would make these junctions _look_ a
bit different from the traditional junctions. But, on second thoughts,
I think what you propose is better, and less confusing. So, the same
example would look something like:

    kind: junction
    config:
      target: junctions/core-libs.bst:junctions/base-sdk.bst
    # other config overrrides stay here as usual

I think we should add checks to verify that we don't get both `target`
and sources.

> Maybe it would make sense to generalize this and define a new element
> kind that acts as symbolic link / alias of another element. And that
> could work for both junctions and regular elements.
>
> Not sure whether this will be very useful for regular elements. It
> could be interesting for situations where multiple implementations
> exist for the same API and you don't want to specify a particular
> implementation in each reverse dependency (similar use case as Debian
> virtual packages). This can easily be emulated with a stack element
> with a single dependency, but that approach doesn't work for junctions.

I have mixed feeling about a generic `alias` element. As you say,
normal elements don't really need it, so it will only be useful for
junctions, nested junctions at that. Given its limited scope, I think
it will probably make things more complicated than they already are,
and doesn't really buys us that much. I have a feeling that this
element kind will likely require some more special casing in the Core,
which is one thing I am hoping to avoid. As in, we don't have to
rethink about the codepaths that check if an element is of kind
junction.

Based on that, I'm leaning towards supporting this usecase by way of a
config option to junction element, rather than creating a new kind.

Let me know what you think.

> Cheers,
> Jürg

Cheers,
Chandan