From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-06-23 09:38:54
David Abrahams wrote:
> > 0. I don't really like the idea that conditional properties are evaluated
> > in context accumulated after evaluation of previous conditional
> > properties. IOW, meaning of conditional properties depends on order. On
> > Jabber, Dave said there was some use case which asked for order-dependent
> > semantic, but could not remember that use case.
> Yeah, part of the problem is that the time between when Ali and I
> had the discussion and when the spec got posted was so long that I
> forgot much of the background thinking and rationale.
> I think it's worth thinking of the move in this context: the idea was
> to try to represent main target alternatives as conditional
> properties. If alternatives themselves can currently have differing
> conditional properites, there's no way to make this representational
> collapse without losing expressivity.
> Of course, I'm now convinced that trying to do that collapse causes
> some real implementation difficulty, and we ought to keep alternatives
> if it's possible to fit them into Ali's proposal without too much
> trouble, so contextual evaluation may not be so important.
> > 1. The 'property-adjuster' is present in current code for a reason -- to
> > make 'direct_request_test.py' work. I agree that it's somewhat complex,
> > but I don't know a simpler solution.
> Again, because of long delays I've forgotten rationale, but we
> considered this carefully. My vague memory is that one of the
> following is true:
> a. we convinced ourselves that direct_request_test.py actually
> *shouldn't* work, and that using the property adjustment could just
> as easily lead to unintuitive behavior in several cases (which of
> course I've forgotten - Ali came up with them)
I'm open for discussion on this. However I recall that some time ago we've
convinced ourself that direct_request_test.py should work. That was without
> b. the way the process is structured actually does handle that
Hmm... I don't see how. Ali, can you comment?
> > 2. select-alternatives is just omitted and no concrete replacement
> > is proposed. In some list discussion, it was said that it's still
> > will be necessary to select only one element from a group --- which
> > makes me wonder if 'select-alternatives' is still needed.
> That was an effect of the knowledge that alternatives can be
> represented as conditional properties. As you've pointed out though,
> just because they *can* doesn't mean they *should*.
> > 3. The 'addProperty' method in the proposal adds properties to
> > this->"usage-requirements" --- but it cannot do that. Main target can be
> > generated with different properties and different usage requirements
> > can be generated.
> Yeah, that looks like a problem.
> > I suspect that fixing this problem will make usage
> > requirements processing similiar to the current one.
> It seems to me that the fix is to append to t->"usage_requirements"
> instead. Isn't that simple enough? After all, usage requirements
> are only taken from already-realized targets elsewhere. A few lines
> Target t = findAndRealize( "property"->value );
> for p in t->"usage-requirements"
Yep, something like this is possible. OTOH, note that currently usage
requirements are no longer associated with virtual-targets, but are returned
by 'generate' method. It's surely possible to make addProperty assign to
> > 4. The current code does something complex with sources.
> You say that like it's a *good* think <wink>
> > It groups all virtual target generated from the same main target
> > dependency together. This allows to issue a warning about unused
> > source only if no virtual target from a single main target was
> > consumed.
> Can you give a concrete example, please?
The example is shared libraries on windows. You get two virtual targets for a
library. Only one is consumed, but the system notes that the other one *is*
consumed, and does not produce the warning. Of course, your generator
algorithm should take care of it --- but only when it's ready.
> > 5. How initial value of 'usage-requirements' is converted into value
> > that is returned is not specificed. In particular, it's not stated
> > what is done with conditional properties and dependency properties.
> In which step of the pseudocode, please?
That's the point --- there's no step of pseudocode which handles it. Main
target has "usage requirements" attribute, which can contain conditional and
dependency properties. Pseudocode only appends to this->"usage requirements".
How user-specified value is processed is not specified.
> > 6. It was suggested long ago that library sources are treated
> > intelligently. I.e. library which is source of another statically
> > linked library would automatically become usage requirement. Is it
> > possible with the proposed algorithm? How?
> I think we need to make progress on the other issues before we tackle
> this one.
No problem with me.
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