Re: [jamboost] Re: Spec comments

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.

OK.

> > 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 
Ali, though.

> b. the way the process is structured actually does handle that
> case.

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*.

Okay.

> > 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
> up:
>
> 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
variable.

> > 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.

- Volodya