|
| Re: [buckminster-dev] question about generators and/or 'just in time' building of dependencies [message #15303 is a reply to message #15236] |
Fri, 11 April 2008 07:03   |
|
Hi Todd,
yes, you're right. This is exactly the kind of problem the <generator> element is intended to solve.
In your case you can declare a generator that appoints an attribute representing the bulk of the
component X. The attribute can be an artifact (i.e. something that exists and is ready to use as is)
or an action that produces the X component.
The setup should be fairly simple. Details about the declaration can be found here:
http://wiki.eclipse.org/Buckminster_component_meta-data_lang uage_%28Reference%29_-_LATEST#Generators_component
The important thing to know is that in the tree of components, the generator must be declared before
it is used so that the resolver, when it encounters the dependency to X, knows that X is generated
and hence not expected to be resolved the normal way. The component A that expresses a dependency to
X will not know how X came into existence. So you have two options:
Declare yet another top component T that declares the generator for X and a dependency to A and B, i.e.
<cspec name="T">
<dependencies>
<dependency name="A"/>
<dependency name="B"/>
</dependencies>
<generators>
<generator generates="X" component="B" attribute="X_attr"/>
</generators>
</cspec>
then point your query to T instead of A (you can add a skip node for T to the MSPEC if you don't
want that component materialized).
The alternative is perhaps cleaner. You put B at the top of the tree, i.e. you let B depend on A:
<cspec name="B">
<dependencies>
<dependency name="A"/>
</dependencies>
<generators>
<generator generates="X" attribute="X_attr"/>
</generators>
...
</cspec>
and then point your CQUERY to B instead of A. You cannot skip B of course. It has to be materialized
in order to create X.
Please note that if the generator is declared in another component then B, the "X_attr" must be a
public artifact/action.
I hope this helps,
- thomas
Todd_Lee@amis.com wrote:
> I've got a couple of non-java (python) projects that I'm trying to
> 'buckminsterize' - The relation is something like this:
>
> Component A depends on artifact X contained in Component B
>
> So I've set up the dependencies so that when I call my top level cquery
> (dependent on Component A) I get a workspace with both Component A and
> Component B materialized (I'm working in the IDE right now). I've created
> buckminster.cspec's for both components as well as build.xml wrappers for
> the actual python build operations.
>
> I'm wondering if there's a way (I'm sure there must be, so I guess the
> question is really 'what's the recommended way') to build Component B so
> that artifact X is ready and waiting when Component A looks for it to
> fulfill the build-time dependency? Looking at the documentation, it would
> seem that perhaps this is the role of the 'generator' element in the cspec,
> but I'm not clear on how it should be implemented. Any help would be
> greatly appreciated.
>
> Thanks!
> Todd
>
>
> Todd Lee
> Software Tools
> ON Semiconductor
> Tel: +1.519.884.9696 ext 2242
> Fax: +1.519.884.0228
> E-mail: todd_lee@amis.com
>
|
|
|
| Re: [buckminster-dev] question about generators and/or 'just in time' building of dependencies [message #15336 is a reply to message #15303] |
Sun, 13 April 2008 14:18 |
 Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Hi,
This got me thinking a bit - how to support a case like "use pre-built
or build"?
What if the resolver does not give up if it finds an unresolved
component (like the generated X), and instead waits until it has
gathered all resolveable components. Then it checks if any of the
components are capable of producing the component X?
Then in the rmap (I guess), you would indicate if you want to look for
prebuilt X before building it.
Or are there other ideas for how to solve this?
- henrik
Thomas Hallgren wrote:
> Hi Todd,
> yes, you're right. This is exactly the kind of problem the <generator>
> element is intended to solve. In your case you can declare a generator
> that appoints an attribute representing the bulk of the component X. The
> attribute can be an artifact (i.e. something that exists and is ready to
> use as is) or an action that produces the X component.
>
> The setup should be fairly simple. Details about the declaration can be
> found here:
> http://wiki.eclipse.org/Buckminster_component_meta-data_lang uage_%28Reference%29_-_LATEST#Generators_component
>
>
> The important thing to know is that in the tree of components, the
> generator must be declared before it is used so that the resolver, when
> it encounters the dependency to X, knows that X is generated and hence
> not expected to be resolved the normal way. The component A that
> expresses a dependency to X will not know how X came into existence. So
> you have two options:
>
> Declare yet another top component T that declares the generator for X
> and a dependency to A and B, i.e.
>
> <cspec name="T">
> <dependencies>
> <dependency name="A"/>
> <dependency name="B"/>
> </dependencies>
> <generators>
> <generator generates="X" component="B" attribute="X_attr"/>
> </generators>
> </cspec>
>
> then point your query to T instead of A (you can add a skip node for T
> to the MSPEC if you don't want that component materialized).
>
> The alternative is perhaps cleaner. You put B at the top of the tree,
> i.e. you let B depend on A:
>
> <cspec name="B">
> <dependencies>
> <dependency name="A"/>
> </dependencies>
> <generators>
> <generator generates="X" attribute="X_attr"/>
> </generators>
> ...
> </cspec>
>
> and then point your CQUERY to B instead of A. You cannot skip B of
> course. It has to be materialized in order to create X.
>
> Please note that if the generator is declared in another component then
> B, the "X_attr" must be a public artifact/action.
>
> I hope this helps,
>
> - thomas
>
>
> Todd_Lee@amis.com wrote:
>> I've got a couple of non-java (python) projects that I'm trying to
>> 'buckminsterize' - The relation is something like this:
>>
>> Component A depends on artifact X contained in Component B
>>
>> So I've set up the dependencies so that when I call my top level cquery
>> (dependent on Component A) I get a workspace with both Component A and
>> Component B materialized (I'm working in the IDE right now). I've created
>> buckminster.cspec's for both components as well as build.xml wrappers for
>> the actual python build operations.
>>
>> I'm wondering if there's a way (I'm sure there must be, so I guess the
>> question is really 'what's the recommended way') to build Component B so
>> that artifact X is ready and waiting when Component A looks for it to
>> fulfill the build-time dependency? Looking at the documentation, it would
>> seem that perhaps this is the role of the 'generator' element in the
>> cspec,
>> but I'm not clear on how it should be implemented. Any help would be
>> greatly appreciated.
>>
>> Thanks!
>> Todd
>>
>>
>> Todd Lee
>> Software Tools
>> ON Semiconductor
>> Tel: +1.519.884.9696 ext 2242
>> Fax: +1.519.884.0228
>> E-mail: todd_lee@amis.com
>>
|
|
|
| Re: [buckminster-dev] question about generators and/or 'just in time' building of dependencies [message #15369 is a reply to message #15336] |
Sun, 13 April 2008 15:40 |
|
Henrik Lindberg wrote:
> Hi,
> This got me thinking a bit - how to support a case like "use pre-built
> or build"?
>
> What if the resolver does not give up if it finds an unresolved
> component (like the generated X), and instead waits until it has
> gathered all resolveable components. Then it checks if any of the
> components are capable of producing the component X?
>
This would be possible but it would also implicitly make all resolution attempts become a "continue
on error" kind since every branch must continue to the bitter end. As it is now, a resolution can be
quickly discarded as soon as something is encountered that cannot be resolved.
> Then in the rmap (I guess), you would indicate if you want to look for
> prebuilt X before building it.
>
I think that the normal case when a generator is used is the result of very a conscious design and
the generator declaration is an integral part of the build system that you have defined in the
top-component. I.e. the top-component is tailor-made to drive the build-system that uses the generators.
The components that express dependencies to the generated component has however no knowledge about
it being generated. In another constellation (not using the top-component that contains the
generator), the resolver would proceed in a normal way in order to find the component.
The normal way to distinguish between the build or use pre-built cases, would then be to either use
the CSPEC that declares the generator at the top or to use some other constellation.
- thomas
|
|
|
Powered by
FUDForum. Page generated in 0.03193 seconds
] 
Search
Help
Register
Login
Home
