Re: [jamboost] Targets and projects update

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-05-11 13:41:00

----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>

> I'll try to clarify. There are abstract, virtual and actual targets,
which
> definitions are given at the top of the file.
>
> Abstract targets form a long hierarchy. First, there are
> project-targets, they are just containers for main targets.
> Main-targets, also derived from abstract-target, are just containers for
> variants, which are derived from 'abstract-target'. Classes that will be
used
> for variants are actually the most important. There's class with common
> functionality 'basic-target' and I plan to have two derived classes.
>
> First, 'make-target' will correspond to 'make' rule invocation. Second,
> 'typed-target' will correspond to rules such as "exe", "lib", etc. where
the
> target type is defined.

Good, that is perfectly clear!
A UML diagram would help.

> 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 (?).

> 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"?
(and what does "build" mean, precisely?)

> - call 'construct' rule that will be declared in the most derived class

Which, in general, does what?

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

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

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

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

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

No comment from you on this?

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

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

-Dave