Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-04-23 09:49:43


David Abrahams wrote:

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

Sure! Actually, it's not possible to set locations before make is called,
because of subvariants.

make a.exe : ....

How can you set location on "a.exe"?

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

Here's a more precise definition:
Initial build requests results, after expansion, in several build properties.
Properties used for building certain target are computed by modifying the
build properties as detailed before:

When building a project:
project requirements are combined with requrested build properties
The result is passed to 'generate' method of all main targets

When building a main target:
(*) main target requirements are combined with requrested build properties
The result is passed to 'generate' methods of all sources without
explicit properties.
For sources with explicit properties:
explicit properties are combined with the result of (*) step
they are passed to 'generate' rule of the source.
(Since sources are main targets as well, process may repeat)

My proposal is that "combining-properties" issue a warning when
link-compatible property is overrided, and fail when link-incompatible
property is overrided.

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

I would say that every feature can override a value in build variant.

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

:-)
But it is. I thought the problem is due to test itself, but seems like
there's something wrong with project.jam.

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

First, there's subvariant path generation.
Second, is to implement apply-requirements and compose-requirements.
Third, is to rename "typed-target" to "main-target" and make it store
variants of build actions.
Fourth is implementation if "main-target.generate" -- should
apply-requirements, call generate rules for sources, and build dependency
graph.

I currently plan to grab project.jam and attach "site.jam/user.jam",
"--toolset/--build" to it and make sure project-test1.py works.

- Volodya

 


Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk