From: David Abrahams (gclbb-jamboost_at_[hidden])
Date: 2003-06-05 10:07:03
Vladimir Prus <ghost_at_[hidden]> writes:
> David Abrahams wrote:
>> Vladimir Prus <ghost_at_[hidden]> writes:
>> > Hmm... the first one should be converted to NM_ASM. The generator should
>> > produce targets in fixed order, I believe.
>> A generator with signature A -> B B produces two Bs at the same
>> time. Am I missing something?
> True. However, the first CPP returned is always the one which must be
> processed further.
Seems totally arbitrary.
What's the basis for that rule?
What if both need to be processed further?
>> What element of the system other than your parenthesized note (which
>> I don't believe can be captured in code) indicates that the first one
>> should be converted instead of the 2nd one?
> In the current system you can describe it by creating a generator STATIC_DATA
> <- ECPP, which will
> 1. Create CPP from ECPP by recursive call to 'generators.construct'.
> 2. Take a first CPP and convert it to NM_ASM by another call to
> 3. Convert NM_ASM to STATIC_DATA
> 4. Return STATIC_DATA and the second CPP
> If you take a look at Jamfile for part of this example, still at
> you'll notice similiar approach.
As far as I can tell, if you have a system which solves this
particular problem in the way you want, it's just because the system
has been tuned for this particular problem. I don't think it
> It's not automatic, but user can be asked to do such things for
> complex transformations. And it must be able to do that.
Why not just declare intermediate main targets? It seems so much
simpler and more-predictable.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk