Re: [boost] Re: Re: Trying to learn build system

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-07-08 14:33:54

----- Original Message -----
From: "Gennadiy Rozental" <rogeeff_at_[hidden]>
Newsgroups: gmane.comp.lib.boost.devel
To: <boost_at_[hidden]>
Sent: Monday, July 08, 2002 3:09 PM
Subject: [boost] Re: Re: Trying to learn build system

> >
> > > 2. How Jam find what needs to be done to update the command?
> >
> > That question is totally unintelligible to me.
> I meant update the target.
>
> Would the following statement be correct:
> Actions that were attached during parsing stage and have  "the  target"
as
> one of the argument will be executed during update stage to update this
> target.

Close. I think it's more like:

Actions that were attached during parsing stage and have  "the  target" as
 one element of the first argument will be executed during update stage to
update this target.

But there may be a little more to it than that -- I'm not sure if the
sources (2nd argument) and whether they're out-of-date are taken into
account.

> > > 5. Is there way to define an action but for internal use only, i.e.
so
> > that
> > > user would not be able to invoke it?
> >
> > Use a funky name they'd never think of.
>
> What about local rule syntax?

I'd stay away from using local rules for v1, since no module boundaries get
defined.

> > > 6. Could somebody explain in simple words deal with "grist"?
>
> bin
>  +-proj_root
>  | +-A
>  |  | +-Jamfile
>  | +-B
>  |  | +-Jamfile
>
> Let imagine that both A and B directories have a Jamfiles that defines
> library my_lib that builds from my_source.cpp. Let say we are in the
> directory A.
>
> lib my_lib : my_source.cpp ;
>
> What will bjam command line be to do a follwing tasks:
>
> 1. build debug version of my_lib that in a directory A

bjam -sTOOLS=... my_lib

> 2. build debug version of my_lib that in a directory B

Go to directory B, and do the same thing

> 3. build spead optimazed version of my_source.o in a directory A

bjam -sTOOLS= -sBUILD=release my_source.o

> Would it be correct to say that:
>
> 1. Target names in dependancy tree does not coinside with the names user
> specify in Jamfile. Instead they are gristed using following information:
> subproject name, variant and subvariant. Also bjam during pasring stage
adds
> dependancy between user targets and real gristed targets.

Yep.

> 2. Term main target means gristed user target

I think so, it's been a while...

> 3. Gristed name for target that builds all size optimazed libraries in
> subproject root/proj1/subproj2 would be:
> <proj1!subproj2/optimization-size>lib

Not sure. Try it with -d+3 and find out.

> In source list we see <lib>some_lib. What is <lib> there? Grist?

Syntactically it's grist. Semantically it means "find a target of this
type".

> How jam find real target name?

Use the source, luke.

> What about requirenment syntax, is it also grists?

Syntactically it's grist. It serves a different purpose from target grist,
though.

> 7. Let say:
> X = a b c d ;
> How many times the some-rule will be invoked here:
>
> some-rule $(X)

Once.

> Let define some-rule like this:
>
> rule some-rule ( arg )
> {
>     return $(arg) ;
> }
>
> What will be the value of following expression:
>
> [ some-rule $(X) ]

Error. You can try this yourself with jam -f-:

C:\boost\tools\build>bjam -f-
X = a b c d ;
rule some-rule ( arg ) { return $(arg) ; }
some-rule $(X) ;
^Z
-:3: in module scope
*** argument error
* rule some-rule ( arg )
* called with: ( a b c d )
* extra argument b
-:2:see definition of rule 'some-rule' being called

> The same question by some-rule defined like this:
>
> rule some-rule ( arg + )
> {
>     return $(arg[1]) ;
> }

a