Boost logo

Boost-Build :

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

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

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:
> 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?

> 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
> a.obj/release/runtime-link-dynamic/main-target-a.exe/a.obj

In principle, this sounds OK to me.



Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at