Re: [jamboost] Development plan

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-04-19 03:17:00

David Abrahams wrote:

> > ..........
> Good! Please add all clarifications to the document in CVS. Hmm, maybe
> the above stuff belongs in architecture.html...

I'll do it. (When we agree on other issues)

> > > Is it important that dependencies and locations are already
> > > prepared? If so, why?
> >
> > Yes, because dependecies and location are handled by the build system.
> > We don't want some generating rule to override those decisions, especiall
> > about locations.
>
> Are you proposing to do away with binding via $(SEARCH) and $(LOCATE)?

No. Let me try again. 'gcc-link' rule should know how to generate build 
actions given actual jam targets. I belive that it makes no sense to ask that 
rule to set any dependecies, or set locations. Otherwise, each link rule 
would have to set SEARCH and LOCATE, and invoke some rule to get those 
locations. That would be boring and that code would be the same in all 
'*-link' rules. So, I propose that 'gcc-link' would be as simple as:

rule gcc-link ( target : sources + : requirements) {
# Example only
if <debug-symbols>on in $(requirements)
{
OPTIONS on $(target) = -Os ;
} 
}

actions gcc-link 
{
gcc $(OPTIONS) -o $(<) $(>)
}

>
> > > > [I would like to retain the same interface for all rules that
> > > > actually generate build actions. The current "flags" rule is
>
> nice
>
> > > and
> > >
> > > > should be carried over, but passing properties as well would
>
> make
>
> > > > sure everything is possible.
> > >
> > > I don't see a relationship to the flags rule, but I agree that the
> > > generating rule should get build properties explicitly.
> >
> > When we have flags rule, then rule 'gcc-compile' may be empty, because
> > relevant variable will be set on targets thanks to flags rule.
>
> Ah, sorry: when I said I wanted to keep the flags rule, I meant that I
> wanted to keep the basic interface. I don't think "flags" should do any
> work itself, but should be declarative like everything else <wink>. So
> gcc-compile should exploit the data generated by all of the appropriate
> flags calls.

I don't think "flags" should do any work too. But we'd need convenient enough 
may to use it. At the very least, we'd need something like

rule gcc-link ( target : sources * : requirements )
{
set-target-variables target : requirement ;
}

I think that calling 'set-target-varibles' automatically before calling 
'gcc-link' might be a good idea.

> > targets. You've previously remarked that is similar to
>
> declare-local-target.
>
> > Does that rule allow NOTFILE targets?
>
> I haven't thought about it. Maybe not, but I never explicitly ruled them
> out.

We'd need to think about it, then :-)

> Then please explain what you mean by "will also be available as actual
> jam targets with plain names".

If some Jamfile contains:

make a.exe : .....

Then you can say

bjam a.exe 

in the directory of that jamfile. BTW, m1-02.py tests for this around line 40.

> > I believe this is explained in
> > http://groups.yahoo.com/group/jamboost/message/781
>
> It doesn't explain the sentence about prefering longer requirements
> lists.

True, We'd certainly need some selection mechamism. Longer requirements list 
is my first guess at such mechamism.

> > > > All properties will be considered relevant for the generating
>
> rule
>
> > > for
> > >
> > > > the purpose of computing subvariant identifier.
> > >
> > > Now there's a slight contradiction. If you have to compute a
> > > subvariant identifier, then you aren't starting with a true Jam
>
> target
>
> > > name, because the target will have to acquire some grist to identify
> > > the subvariant.
> >
> > Yes, actual jam targets will need grist. I don't understand the
> > contradiction.
>
> Earlier you took great pains to say that the first argument to make is
> already a true Jam target name. Now you're implying that grist must be
> added to get the target name. Which is it (or have I misunderstood?)

I think you've misunderstood me. The arguments to generating rules are true 
jam targets. The arguments to make rule are not. They have 1-1 correspondence 
with file names:

make a.exe : ...

will always result in generating file named "a.exe", but location of that 
file will be decided by the build system. The name of actual jam target 
passed to generating rule will have appropriate grist. In addition, a real 
jam target name "a.exe" will be available, as I've explained above.

> > > Yes, definitely. Otherwise, it will be hard for people to understand
> > > why targets are skipped.
> >
> > Okay. It could just return an error string it that case, which can be
> > distinguished for correct return by the absense of grist, right?
>
> A little too subtle. Why don't we pick some nice, identifiable first
> element like '@error'?

Okay. 

> > BTW, what will happens if parant require <optimization>space and
> > current project <optimization>speed (link-compatible features). Or
> > <rtti>off and <rtti>on, respectively (link-incompatible features).
> > Seems like we don't understand something here.
>
> I agree. Generally these won't be used as requirements, but as
> default-build settings. However, I can see that they might be.
>
> OK, <rtti>on/off - I think this is simple: we just refuse to build the
> parent. In general, linking would fail anyway.
>
> As far as <optimization>on/off is concerned, it seems to me that we
> should respect the requirements of the child when building the child,
> rather than propagating the parent requirements. Doesn't this sound very
> much like "request compatibility" as discussed here:
> http://groups.yahoo.com/group/jamboost/message/786?

Yep. Here how I would describe the mechanism
We have a build request and then (for example): project requrements, 
main target requirements, additional properties requested for another target 
used in that main target and requrements for that second targets. 
Any attempt to add link imcopatible property at any stage prevents building.
Any attempts to change link compatible non-free property emits a warning, but 
building succeeds. Does that sound logical enough?

Note that we might want different kinds of diagnostics for different 
violations of the above rule, but that's secondary question.

> > > > 2. Another possibility is to specify which features
>
> are
>
> > > > compatible. But I belive that number of truly
> > > > incompatible features is low, and explicitly writing
> > > > down all compatible combinations will be harder.
> > >
> > > I agree. I think it makes sense to write down which properties are
> > > link-compatible with one another, as in gLINK_COMPATIBLE, but (if we
> > > need to specify this at all) to write down which features are NOT
> > > compatible with one-another. Put simply, there should be sensible
> > > defaults: the default for features is that they are link-compatible
> > > with one-another.
> >
> > Not sure I understand. Do you propose that features are by default
> > link-compatible with one another and value of one feature are
>
> incompatible?
>
> Yes (except for free features, which may be multi-valued), that's the
> status quo.
>
> >I
> >
> > was proposing something different -- link-compatibility by default for
>
> both.
>
> > Will need to just count the number of link-compatible and
>
> link-incompatible
>
> > properties in existing toolsets.
>
> Aha! I am beginning to see the light. I think you are saying that values
> of a given non-free feature should be considered link-compatible by
> default, 

Yes.

> and that *some other mechanism* should be used to deal with
> overriding features in build requests (i.e. the fact that the user can
> override <optimization>off in his debug build by explicitly specifying
> <optimization>on).

Sorry, but I don't understand why that separate mechanism is needed. If debug 
variant specifies <optimization>off and build request is:

debug <optimization>on

then when expanding composite property "debug" it will be noted that 
<optimization>on is exlicitly specified. I don't see any problems.

> > > > ** Full implementation of abstract-target.generate **
> > >
> > > Can you describe the signature for this rule? I don't see a class
> > > "abstract-target" anywhere.
> >
> > See the class 'target', defined in "targets.jam" (which is in CVS).
>
> Actually,
>
> > the generate rule should take not build request but an element of
>
> expanded
>
> > build request -- i.e. property set.
>
> Okay. Separate nits:
>
> 1. Parse errors:

I'll fix them (by doing what you suggest later)

> 2. I can't get used to the C++-style separation of interface and
> implementation, and frankly I don't think the Jam language lends itself
> to it. It makes it especially hard for me to evaluate the code because
> there aren't any comments next to the implementations to guide me. I
> would really appreciate it if you'd just move the comments to the
> implementations and eliminate the empty interface specifications in the
> beginning of the file. Rene's system will help us get a coherent
> interface document that doesn't include implementations.

I'll do it.

> > > > It should
> > > > - filter build request with requirements
> > > > - select appropriate variants of used targets
> > > > - construct a dependecy graph for target
> > > > - return it.
> > > >
> > > > The depencency graph construction at this stage will be
> > >
> > > implemented using
> > >
> > > > call to construct.construct
> > > > rule construct ( target : target-type : sources * :
> > >
> > > properties )
> > >
> > > Why pass the target-type? It seems to me that the abstract target
> > > should know its target-type.
> >
> > Abstract target known it's type. But "construct" deals with dependency
>
> graph
>
> > construction -- abstract target would call it passing it's own target
>
> type.
>
> Still seems redundant to me, since it passes itself as the first
> argument. Not a big deal, though.

Let's decide when we need that functionality.

> > > I don't understand the above. Sorry that I need so much
>
> clarification.
>
> > main target has it's generate rule called. It decides, which make
>
> invocation
>
> > for this main target name should be used.
>
> Now I begin to get a hint of the "requirements length preference" thing
> you described earlier.
>
> > A target subvariant name is
> > computed (assuming that all properties are relevant, we'd just use all
>
> the
>
> > properties). A virtual target is creates for the target and for each
>
> source.
>
> > And action associate with target will be just invocation of the
> > generating-rule given in the make invocation.
>
> Very nice, thank you.
>
> > > > [it is possible that we generate more than one target because
> > > > build actions create more than one. Handling of this is
>
> specified
>
> > > > in architecture.html and should be implemented.]
> > >
> > > That document describes a very un-hardcoded system, so I can't
>
> resolve
>
> > > this with the previous sentence.
> >
> > I meant that we should be prepared that target's generate rule will
>
> return
>
> > list of virtual targets separated by "@". (In fact, for main target
>
> there
>
> > should be only one virtual target, possibly followed by "@" and a list
>
> of
>
> > other virtual targets that we can't avoid generating due to tools
>
> used).
>
> > However, it seems that we'll never use "@" in M1, so the above
>
> paragraph can
>
> > be forgotten.
>
> Done ;-D

:-)

Now. let's consider what we can actually do. I can see this topics:
1. Make project-test1.py work again -- which would assure we have correct 
initialization semantics.
2. Accept '--toolset' and '--build' options, formulate build requrest,expand 
it, and pass to 'generate-rule' of a project target.
3. Combine project requrements
4. Create another class, corresponding to single 'make' invocation, and make 
'typed-target' (class which implements main target to select right one)
5. Generate dependency graph. 
6. Make 'virtual-target' use correct target location.

I'm really not sure how will we do that. I won't have any time till April 23 
(inclusive), and neither like idea of blocking others or of asking others to 
dig into project.jam and targets.jam :-) However, collaboration on 
targets.jam would really be good -- it's very far from been finished.

- Volodya