Re: [jamboost] Development plan

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-04-22 16:20:32

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

> > > > 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 $(<) $(>)
> }
>

Yes, fine. So what you really mean to say, I think, is that other parts
of the build system will handle setting of locations and dependencies,
and there is no need to do it in the rule which is an argument to make.
It seems to me that there should also be no requirement that the
dependencies and locations be set *before* make is called.

> > 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.
"either" ;-) ------------------------------^^^

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

Yes! Then gcc-link may be reduced to an action.

> > I haven't thought about it. Maybe not, but I never explicitly ruled
them
> > out.
>
> We'd need to think about it, then :-)

OK, we can rule it out until it's sufficiently thought through.

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

That seems reasonable to me.

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

I understand and it seemed fine to me.

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

OK.

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

OK.

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

Yes, but not nearly precise enough. What is the meaning of the list
beginning with "project requirements..."? What is the definition of
"second targets"? What constitutes an "attempt to add a property"? What
consitutes an "attemp to change a property?" You get the idea...

I'm not just being pedantic: I don't understand the meaning of your
statement the way it's written.

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

I don't either. I think I was wondering "what are the criteria for
allowing particular features to be overridden in build requests?"

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

Oh, I didn't know it was busted!

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

I'll poke at it. Please feed me small chunks to do. What needs to be
done next?

-Dave