Re: [jamboost] Targets and projects update

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-05-13 06:28:23

David Abrahams wrote:
> ----- Original Message -----
> From: "Vladimir Prus" <ghost_at_[hidden]>
>
> > I'll try to clarify ....
>
> Good, that is perfectly clear!
> A UML diagram would help.

I'll think about it.

> > Maybe it would be better to describe how tagets will be generated.
> >
> > 1. A 'project-target' for project in "." is retrived and its 'generate'
>
> rule
>
> > is called.
> > 2. For all main targets and for all subproject, call they 'generate'
>
> rules
>
> > 3. In each main targets, 'generate' rule for each variant is called. Now
>
> only
>
> > one can return non-empty list of virtual targets.
>
> I presume this is because generate takes a single build configuration
> (element of an expanded build request) as a parameter, and you only want to
> build on variant per element of the build request (?).
-----------^^ "one"?

Yes, I want to select one variant for main target for each element of the 
build request. I was proposing to use the variant with the longest list of 
requirements if there two alternatives but have not implemnted this yet.

> > 4. Class for main target variant can do anything in general, but those
> > derived from 'basic-target' will:
> > - refine required properties with requirements
> > - build source targets
>
> Another target type! What's a "source target"?

A "source target" is a term that we've agreen on some time ago -- it is 
source of a rule which is not file, but is main target itself.

> (and what does "build" mean, precisely?)

call 'generate'

> > - call 'construct' rule that will be declared in the most derived class
>
> Which, in general, does what?

It is respondible for constructing the dependency graph for the main target 
variant. For example, it might be given virtual targets corresponding to two 
cpp files and will generate a dependency graph for an executable.

> > > So, is local-name really the same as the name of the main target?
> >
> > Yes. I used this name for variable because of mental connection with
> > 'declare-local-target'.
>
> I'd prefer "name", I think. Is this also a target id? If so, id is better
> (more formal).

What's target id? I don't remember this term was ever defined.

> > > # Generates virtual targets for this abstract target which match
> > > # 'properties' as closely as possible.
> > >
> > > Hmm, what does "as closely as possible" mean?
> >
> > Oh... We need to decide this. If user gives some build request, are there
>
> any
>
> > constaints on what properties can be used for building, except that they
>
> must
>
> > be link compatible with the requested ones?
>
> I don't see why there should be additional constraints. Did you have
> something in mind?

No. Which means that "as closely as possible" should be removed, and the 
comment will become
# Generates virtual targets for this abstract target. Properties for the 
# virtual targets will be link-compatible with 'properties' and will include 
# all free features from 'properties'.

Is this OK?

> > > # always bring in the rules defined from this module, so that
> > > # users can easily call "inherit", for example.
> > > import class : * ;
> >
> > Welll.... but when I comment that line out, project-test2.py fails!
>
> Shouldnt'
>
> > the fragment you quote be moved to the 'instance' rule?
>
> You're probably right. Why don't you make that change?

Done.

> > > 1. the trick with "@" is possibly too tricky. It took me a long
> > > time to grok, and at least needs more explanation.
> >
> > The actual problem is that we seem to need a list where each element can
>
> be
>
> > list itself. How do we implement that?
>
> It ain't easy; most approaches are hacks. Your trick might be as good as it
> gets. You could write a "Jam expression parser" and build lists as space
> separated elements. Of course you'd need to quote any embedded spaces.

I'll have to look at Rene's container.jam now

> > > 2. It looks like @error messaages are just discarded. Intentional?
> > > If so, say so in a comment.
>
> No comment from you on this?

Yes this is intentional. I mean that we try all the variants for main target 
and only one should succeed. All the others can fail.

> > > I tried to answer your questions posed in the comment above
> > > basic-target.generate the other day. Did that work for you? I'm
> > > actually unclear on the relationship of this generate rule to the
> > > search process we came up with in the design process.
> >
> > Oops! I though I've responded that email of yours, but I don't see that
> > message either in sent or in drafts. While I'm looking for it, it's
>
> enough to
>
> > say that I'm unclear the relationship either.... so this rule might need
> > change when we start implementing generators.
>
> Hmm... OK, I'm flexible, but we should clarify that soon.

Guess we can clarify both 'generate' behavour for basic-target and subvariant 
paths when we start implementing generators.

> > > I object to the idea of naming a rule "recurse": it just describes an
> > > implementation technique, not what the rule does. Can you do something
> > > more descriptive?
> >
> > 'generate-source' is what I came up with.
>
> It's a start.

Good. I'll make the rename.

- Volodya