Re: [BuildStream] How to synchronize nested junctions

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
      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

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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]