Re: [jamboost] subvariants questions

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
described
> > in the architecture document?
> > Why not say that generators are only allowed to make property set
changes
> > 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
matching
> 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
have
> 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
better
> >
> > UI
> >
> > > ("in case user wants to get some subvariant and do something with
it"),
> >
> > 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
possible
> > 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
need
> > a way to identify a subvariant based on how it's built. In other words,
we
> > can't just try to assign consecutive numbers to each subvariant and use
a
> > directory associated with that number.
>
> 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. 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
the
> idea that nothing requires us to store objects used by main targets
together
> 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
path
> would be
>
> a.obj/release/runtime-link-dynamic/main-target-a.exe/a.obj
b.exe?----------------------------------------------^^^^^

In principle, this sounds OK to me.

-Dave