From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-06-28 08:06:53
David Abrahams wrote:
> > In "Virtual Target Generation", the fourth paragraph reads:
> AFAICT that paragraph was only intended to allow the generator to change
> 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.
stlport would add include path in its "expand" rule, IIRC. Python -- well yes.
> > > > 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
> > > 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.
This appears to be true.
> > > 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
> > easily pick generated files, which is simpler (IMO) when this part is
> > present.
> I tend to disagree.
This is UI issue, so we better ask more people.
> Also we'll make a lot more directories than we need to
> if we go this way.
It seems to me that we can avoid this part for main targets as well.
So, I suggest that we either drop this part for both main and intermediate
targets, or retain it for both.
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