Re: [jamboost] subvariants questions

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

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 
target types

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

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 ;

and 

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

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

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

> > 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
>
> path
>
> > would be
> >
> > a.obj/release/runtime-link-dynamic/main-target-a.exe/a.obj
>
> b.exe?----------------------------------------------^^^^^

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.

- Volodya