[buckminster-dev] Re: Components that come into existence during a build

[Thomas Hallgren <thomas@xxxxxxx>]

kenneth@xxxxxxxxx wrote:
> Something disturbs me about this conversation and it seems to me to get 
> very complicated...as usual maybe I'm missing something...
>
> So far, products from a build (or lets use 'action' since that is the 
> bucky terminology) are artifacts. Artifacts can obviously be turned into 
> components once they exist (and be put in a repository so other 
> components can *then* reference them).
>
> Umm, can't remember right now, but if an artifact can be typed, it can 
> be typed as 'component'. That would mean that the resolvement might be 
> able to intelligently deduce as it goes that either some 'real' 
> component declares that it produces an artifact that is-a component, or 
> that it can be found the traditional manner through the rmap. Either 
> way, resolution can be made.
>
> Materialization is also different - top of my head says that a 
> artifact-being-a-component is never 'materialized' as such, it can only 
> be built through actions when and if they're called, but that should be 
> taken care of the right way through dependencies. In theory, yes, we 
> could let materialization actually let it materialize by ensuring the 
> necessary action is called, but if it's possible to be lazy about it is 
> better...
>
> True, this can also be complicated, but not on the declaration side so 
> much as in the resolvement/materialization (and possibly action) engine. 
> It also adds issues on what to do if the component sought after both 
> appears as an artifact and a 'real' component in a repository. Etc.
>
> I'm worried about introducing a 'subcomponent' construction as I think 
> it muddies the water a lot, especially when we already have the artifact 
> construction. Can a subcomponent have subcomponents? Thomas, you did 
> once pursue the subcomponent idea but abandoned it - true, that was long 
> ago and the rest substantially different from today, but still...
>
> ?
Consider the case when an external prerequisite is referencing a specific action in a 
generated component. If the component doesn't exist, there's currently no way you can 
express that. The action that produces the component is not what you're after.

We need some way of expressing Action 'x' in component 'A' needs the result of action 'y' in 
the generated component 'G'. The CSPEC format can be discussed. Perhaps it's an extension to 
the Action rather then a subcomponent? How would you do the following?

In the CSPEC for A

<dependencies>
  <dependency name="G" subcomponentOf="B"/>
</dependencies>

<actions>
    <public name="x" .../>
       <prerequisites>
          <external component="G" attribute="y"/>
       </prerequisites>
       ...
    </public>
</actions>

In the B CSPEC

<subcomponents>
  <subcomponent name="G" action="create.G"/>
</subcomponent>

Expected flow:
1. Something triggers action A.x.
2. Buckminster wants to resolve the prerequisite G.y.
3. It asks for the CSPEC of G via the dependency.
4. Finds the subcomponentOf="B" declaration.
5. B is brought in and the subcomponent entry for G is obtained.
6. The action 'create.G' is executed.
7. Once completed, the G CSPEC is obtained and returned all the way up.
8. G.y can now be resolved (which in turn might trigger actions in G)

Another side-effect that Henrik and I discussed is how to deal with dependencies in the 
generated component. How do we resolve them? Do we allow them at all? Do we allow that they 
go beyond the dependencies expressed by the generating component? If so, in what scope do we 
materialize them?

Muddy waters, yes. Let's pour some chlorine into it :)

- thomas