Re: [jamboost] subvariants questions

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-06-27 09:24:15

David Abrahams wrote:
> From: "Vladimir Prus" <ghost_at_[hidden]>
>
> > I'm now thinking about targets, subvariants and paths for them and it
>
> does
>
> > not seem as simple as I expected. Before I start writing long messages, I
> > have a quick question -- we were planning that if some target, for
>
> example
>
> > object file, is used by two main targets, and neither has any explicit
> > requirements, than we believe that this object file can be built only
>
> once.
>
> As long as the main targets are in the same (sub)project and so inherit the
> same implicit requirements.
>
> > But... if we allow generators to arbitrary change property set, we cannot
> > guarantee that this two objects use exactly the same set of free
>
> properties.
>
> 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. This means that 
in the general case, two oject used by two different main targets can have 
different set of main requirements. However, seems like we can detect this 
situation.

> > What's more: we can have some intermediate target build with a set of
>
> free
>
> > properties which is not equal to either free properties of its parent, or
> > main target that uses it -- in which directory will be put it.
>
> Why wouldn't we just do what v1 does (generate all such intermediate
> targets in a directory associated with the main target)?

Okay. 

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

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

if its free properties are the same as for its problems. 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

Opinions?

- Volodya