From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-06-28 04:10:18
David Abrahams wrote:
> 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.
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
> > 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
> literal brain.
Suppose you have two main targets:
exe a.exe : a.cpp ;
funky-thing foo : a.cpp ;
The quoted paragraph allows generator for funky-thing to added a bunch of
defines and then continie with the matching process. IOW, the paragraph
permits to change build properties in the middle of transformation sequence.
So, you'll have
a.exe <- a.obj <- a.cpp ;
foo <- a.obj <- a.cpp
but a.obj in the latter case has additional free properties.
> > 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,
I've a gut feeling that you are right.
> 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.
> > Anyway, let' return to the ordinary scheme. In v1 target paths for main
> > targets have the form:
> > main-target-name/<property-list>/main-target
> > for example
> > a.exe/release/runtime-link-dynamic/a.exe
> > 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
> > a.obj/release/runtime-link-dynamic/a.obj
> 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
> > if its free properties are the same as for its problems.
> You must mean "parents", or something------------^^^^^^^^
I meant "Projects they are in" .
> > If the same file is
> > used by b.exe which explicit requirement include free properties, the
> > would be
> > a.obj/release/runtime-link-dynamic/main-target-a.exe/a.obj
Yes, "b.exe". Sorry for another typo.
> In principle, this sounds OK to me.
Good. We'd need the intermediate targets naming scheme when implementing
generators, so it's good we've agreed.
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