From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-06-27 15:07:04
From: "Vladimir Prus" <ghost_at_[hidden]>
> > I assume you're talking about the Build Property Expansion phase
> > in the architecture document?
> > Why not say that generators are only allowed to make property set
> > that are deterministic based on the generator and the set of input
> > properties? Would that handle it?
> I'm not sure. I think that every generator can continue by invoking
> process again, passing *arbitrary* set of properties to it.
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.
> This means that
> in the general case, two oject used by two different main targets can
> different set of main requirements.
I don't see it yet. Please try to be ultra-specific to satisfy my very
> > > And the final question: why do we care which dir is used for storing
> > > particular subvariant. I have a vague feeling that this makes for
> > UI
> > > ("in case user wants to get some subvariant and do something with
> > but
> > > this is poor explanation. Anyone got better?
> > I've asked myself the same question from time to time.
> > I think the biggest issue to keep in mind is that the set of all
> > targets for any run of the build system can't be known in any given run
> > (e.g. because the user may change the toolsets he wants to use), so we
> > a way to identify a subvariant based on how it's built. In other words,
> > can't just try to assign consecutive numbers to each subvariant and use
> > directory associated with that number.
> Well, we can generate CRC or MD5 checksum from complete property set,
We could. I don't think that would be superior to what we've currently got,
though. What we have may be somewhat arbitrary, but I think the
alternatives present some difficulties also.
> Anyway, let' return to the ordinary scheme. In v1 target paths for main
> targets have the form:
> for example
> I like this naming. But when thinking about intermediate targets, I got
> idea that nothing requires us to store objects used by main targets
> with them -- after all, we don't expect anybody to link binaries by hand?
> I therefore propose to make paths for main an intermediate target almost
> uniform. I.e. an object file used by a.exe would be stored in
Why bother with this part?
> if its free properties are the same as for its problems.
You must mean "parents", or something------------^^^^^^^^
> If the same file is
> used by b.exe which explicit requirement include free properties, the
> would be
In principle, this sounds OK to 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