[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[buckminster-dev] Re: Components that come into existence during a build
|
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