Re: [jamboost] subvariants questions

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-06-28 07:32:46

From: "Vladimir Prus" <ghost_at_[hidden]>

> David Abrahams wrote:
> > From: "Vladimir Prus" <ghost_at_[hidden]>
> > Can you point to exactly where in the architecture document you're
thinking
> > that this matching process can be reinvoked? I'm a little unclear on
what
> > we're actually talking about.
>
>
> In "Virtual Target Generation", the fourth paragraph reads:
>
> To produce the dependency graph, a generator may well invoke the
matching
> and target calculation process again on some or all of the source
files,
> with the build property set changed to reflect the generator's input
> target types
>

AFAICT that paragraph was only intended to allow the generator to change
the

<target-type>xxx
and
<target-type-base>xxx

properties. I don't think I was trying to give general leeway over
property-changing at this point...

...though I might be mistaken. Things like stlport and python definitely
have to add #include paths.

> > > Well, we can generate CRC or MD5 checksum from complete property set,
> > > can't we.
> >
> > We could. I don't think that would be superior to what we've currently
got,
> > though.
>
> I've a gut feeling that you are right.

It seems to me that we can still compare the free features we end up with
to the free features implied by the subproject and decide whether the
intermediate target needs its own directory.

> > What we have may be somewhat arbitrary, but I think the
> > alternatives present some difficulties also.
>
> Guess this phrase should be put to docs once we have them.

;-)

> > Why bother with this part?
>
> Because if we provide user-readable paths we'd better provide the ability
to
> easily pick generated files, which is simpler (IMO) when this part is
> present.

I tend to disagree. Also we'll make a lot more directories than we need to
if we go this way.

-Dave