actions bind doc slightly confusion and what variables available in actions?

* question 1:

WebPage:
 
http://boo
st.org/boost-build2/doc/html/jam/language.html#jam.language.
rules.builtins.modifying_binding

contains:

   actions [ modifiers ] rulename 

but also:

   actions bind vars

a little further down.  The second of these suggest that the
'bind vars' 
doesn't mention where the rulename should be, but I guess
one would
assume it follows after the modifiers.  However, this shell
command:

cd ~/prog_dev/boost-cvs/ro/boost/tools/build/v2/
find . -name *.jam -exec grep -e ' bind ' {} ; -ls
actions compile.c++ bind PCH_FILE
actions compile.c bind PCH_FILE
actions link bind LIBRARIES
actions link.dll bind LIBRARIES
6213705   32 -rw-r--r--   1 evansl   evansl      29771 May 
5 08:14 
./tools/gcc.jam
actions link bind LIBRARIES
6213714    4 -rw-r--r--   1 evansl   evansl        510 Nov 
5  2006 
./tools/kylix.jam

indicates to me that the modifiers *follow* the rulename.

Shouldn't the docs be changes?

* question 2

The following is from gcc.jam:
<-------- cut here ---------
actions link bind LIBRARIES
{
     "$(CONFIG_COMMAND)" -L"$(LINKPATH)"

-Wl,$(RPATH_OPTION:E=-R)$(SPACE)-Wl,"$(RPATH)" 
-Wl,-rpath-link$(SPACE)-Wl,"$(RPATH_LINK)" -o
"$(<)" $(START-GROUP) 
"$(>)" "$(LIBRARIES)"
-l$(FINDLIBS-ST) -l$(FINDLIBS-SA) $(END-GROUP) 
$(OPTIONS) $(USER_OPTIONS)
#the above appears all on one line in my editor.
}

 >-------- cut here ---------

What variable values are available in the actions body?  Was
the
'bind LIBRARIES' needed because it wasn't among the set of
variables passed to all actions or just actions for link
commands
or is there some other criteria for determining the
variables
passed to the actions body?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

On 08/03/2007 01:23 PM, Larry Evans wrote:
[snip]
> * question 2
> 
> The following is from gcc.jam:
> <-------- cut here ---------
> actions link bind LIBRARIES
> {
>      "$(CONFIG_COMMAND)"
-L"$(LINKPATH)" 
>
-Wl,$(RPATH_OPTION:E=-R)$(SPACE)-Wl,"$(RPATH)" 
> -Wl,-rpath-link$(SPACE)-Wl,"$(RPATH_LINK)" -o
"$(<)" $(START-GROUP) 
> "$(>)" "$(LIBRARIES)"
-l$(FINDLIBS-ST) -l$(FINDLIBS-SA) $(END-GROUP) 
> $(OPTIONS) $(USER_OPTIONS)
> #the above appears all on one line in my editor.
> }
> 
>  >-------- cut here ---------
> 
> What variable values are available in the actions body?
 Was the
> 'bind LIBRARIES' needed because it wasn't among the set
of
> variables passed to all actions or just actions for
link commands
> or is there some other criteria for determining the
variables
> passed to the actions body?

Part of the answer to this is, maybe, provided by:

http://www.boost.org/doc/html/bbv2/exten
der.html#bbv2.extending.features

which contains:

Then, the flags invocation says that whenever
verbatin.inline-file 
action is run, the value of the verbatim-options feature
will be added 
to the OPTIONS variable, and can be used inside the action
body.

So, are RPATH_LINK, FINDLIBS-ST, FINDLIBS-SA, OPTIONS, and
USER_OPTIONS
all declared as features of the gcc toolset (or more
precisely,
the superclass of gcc, i.e. the unix toolset)?


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Larry Evans wrote:

> On 08/03/2007 01:23 PM, Larry Evans wrote:
> [snip]
>> * question 2
>> 
>> The following is from gcc.jam:
>> <-------- cut here ---------
>> actions link bind LIBRARIES
>> {
>>      "$(CONFIG_COMMAND)"
-L"$(LINKPATH)"
>>
-Wl,$(RPATH_OPTION:E=-R)$(SPACE)-Wl,"$(RPATH)"
>>
-Wl,-rpath-link$(SPACE)-Wl,"$(RPATH_LINK)" -o
"$(<)" $(START-GROUP)
>> "$(>)" "$(LIBRARIES)"
-l$(FINDLIBS-ST) -l$(FINDLIBS-SA) $(END-GROUP)
>> $(OPTIONS) $(USER_OPTIONS)
>> #the above appears all on one line in my editor.
>> }
>> 
>>  >-------- cut here ---------
>> 
>> What variable values are available in the actions
body?  Was the
>> 'bind LIBRARIES' needed because it wasn't among the
set of
>> variables passed to all actions or just actions for
link commands
>> or is there some other criteria for determining the
variables
>> passed to the actions body?
> 
> Part of the answer to this is, maybe, provided by:
> 
> http://www.boost.org/doc/html/bbv2/exten
der.html#bbv2.extending.features
> 
> which contains:
> 
> Then, the flags invocation says that whenever
verbatin.inline-file
> action is run, the value of the verbatim-options
feature will be added
> to the OPTIONS variable, and can be used inside the
action body.
> 
> So, are RPATH_LINK, FINDLIBS-ST, FINDLIBS-SA, OPTIONS,
and USER_OPTIONS
> all declared as features of the gcc toolset (or more
precisely,
> the superclass of gcc, i.e. the unix toolset)?

A rule can use the following variables:

1. Variables globally set in the module an action is in.
2. A variable set "on target"

On Boost.Build, the "on target" variables to set
are described via
the 'flags' rule. So, this line from gcc.jam:

        flags $(toolset).link RPATH_LINK $(condition) :
<xdll-path> : unchecked ;

makes RPATH_LINK available in the 'link' action.

The 'bind' you was asking is somewhat different -- when a
variable used in action
is a string, it can be just used. But when a variable is a
name of jam's low-level
target, one has to use 'bind' to get the pathname inside the
action, not the target's
name.

Finally, I don't really remember if modifiers should be used
before action name
or after -- using 'bind' after apparently works.

- Volodya





> 
> 
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost-build


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

On 08/04/2007 09:30 AM, Vladimir Prus wrote:
> Larry Evans wrote:
> 
>> On 08/03/2007 01:23 PM, Larry Evans wrote:
>> [snip]
>>> * question 2
>>>
>>> The following is from gcc.jam:
>>> <-------- cut here ---------
>>> actions link bind LIBRARIES
>>> {
>>>      "$(CONFIG_COMMAND)"
-L"$(LINKPATH)"
>>>
-Wl,$(RPATH_OPTION:E=-R)$(SPACE)-Wl,"$(RPATH)"
>>>
-Wl,-rpath-link$(SPACE)-Wl,"$(RPATH_LINK)" -o
"$(<)" $(START-GROUP)
>>> "$(>)" "$(LIBRARIES)"
-l$(FINDLIBS-ST) -l$(FINDLIBS-SA) $(END-GROUP)
>>> $(OPTIONS) $(USER_OPTIONS)
>>> #the above appears all on one line in my
editor.
>>> }
>>>
>>>  >-------- cut here ---------
>>>
>>> What variable values are available in the
actions body?  Was the
>>> 'bind LIBRARIES' needed because it wasn't among
the set of
>>> variables passed to all actions or just actions
for link commands
>>> or is there some other criteria for determining
the variables
>>> passed to the actions body?
>> Part of the answer to this is, maybe, provided by:
>>
>> http://www.boost.org/doc/html/bbv2/exten
der.html#bbv2.extending.features
>>
>> which contains:
>>
>> Then, the flags invocation says that whenever
verbatin.inline-file
>> action is run, the value of the verbatim-options
feature will be added
>> to the OPTIONS variable, and can be used inside the
action body.
>>
>> So, are RPATH_LINK, FINDLIBS-ST, FINDLIBS-SA,
OPTIONS, and USER_OPTIONS
>> all declared as features of the gcc toolset (or
more precisely,
>> the superclass of gcc, i.e. the unix toolset)?
> 
> A rule can use the following variables:
> 
> 1. Variables globally set in the module an action is
in.
> 2. A variable set "on target"
> 
> On Boost.Build, the "on target" variables to
set are described via
> the 'flags' rule. So, this line from gcc.jam:
> 
>         flags $(toolset).link RPATH_LINK $(condition) :
<xdll-path> : unchecked ;
> 
> makes RPATH_LINK available in the 'link' action.
> 
> The 'bind' you was asking is somewhat different -- when
a variable used in action
> is a string, it can be just used. But when a variable
is a name of jam's low-level
> target, one has to use 'bind' to get the pathname
inside the action, not the target's
> name.
> 
> Finally, I don't really remember if modifiers should be
used before action name
> or after -- using 'bind' after apparently works.

The following output:
<------- cut here -------

 >------- cut here -------

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

On 08/04/2007 09:30 AM, Vladimir Prus wrote:
 > Larry Evans wrote:
 >
 >> On 08/03/2007 01:23 PM, Larry Evans wrote:
 >> [snip]
[snip]
 > Finally, I don't really remember if modifiers should
be used before 
action name
 > or after -- using 'bind' after apparently works.
 >
The following output:

<------- cut here -------
cd
/home/evansl/prog_dev/boost-svn/ro/boost-trunk/tools/build/v
2/tools/
grep archive gcc.jam
     #~ - The archive builder.
     local archiver =
             : ar : [ feature.get-values <archiver> :
$(options) ] : 
$(bin) : search-path ] ;
     flags gcc.archive .AR $(condition) : $(archiver[1]) ;
         ECHO notice: using gcc archiver :: $(condition) ::
$(archiver[1]) ;
flags gcc.archive AROPTIONS <archiveflags> ;
rule archive ( targets * : sources * : properties * )
     # Always remove archive and start again. Here's
rationale from
     # Originally removing the archive was done by splicing
an RM
     # onto the archive action. That makes archives fail to
build on NT
     # of the archive.
# The 'r' letter means to add files to the archive with
replacement
# Since we remove archive, we don't care about replacement,
but
# The 'c' letter means suppresses warning in case the
archive
actions piecemeal archive

 >------- cut here -------

suggests piecemeal is a modifier and can occur before the
action name (
which in the above output is archive) in an action
definition.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Larry Evans wrote:
> suggests piecemeal is a modifier and can occur before
the action name (
> which in the above output is archive) in an action
definition.

'piecemeal' is indeed a modifier 
<http://www.boost.org/doc
/html/jam/language.html#jam.language.rules.action_modifiers&
gt;. 
And modifiers must be before the actions name, except for
'bind' which 
must be after the name. The exact syntax is:

   `actions` eflags ARG bindlist `{`

So it turns out the bjam docs are a bit misleading in the
case of 'bind 
vars'.


-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software
.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

On 08/04/2007 09:30 AM, Vladimir Prus wrote:
> Larry Evans wrote:
> 
>> On 08/03/2007 01:23 PM, Larry Evans wrote:
>> [snip]
>>> * question 2
>>>
>>> The following is from gcc.jam:
>>> <-------- cut here ---------
>>> actions link bind LIBRARIES
>>> {
>>>      "$(CONFIG_COMMAND)"
-L"$(LINKPATH)"
>>>
-Wl,$(RPATH_OPTION:E=-R)$(SPACE)-Wl,"$(RPATH)"
>>>
-Wl,-rpath-link$(SPACE)-Wl,"$(RPATH_LINK)" -o
"$(<)" $(START-GROUP)
>>> "$(>)" "$(LIBRARIES)"
-l$(FINDLIBS-ST) -l$(FINDLIBS-SA) $(END-GROUP)
>>> $(OPTIONS) $(USER_OPTIONS)
>>> #the above appears all on one line in my
editor.
>>> }
>>>
>>>  >-------- cut here ---------
>>>
>>> What variable values are available in the
actions body?  Was the
[snip]

> A rule can use the following variables:
> 
> 1. Variables globally set in the module an action is
in.
[snip]
In the build.v2 .xml's at:

   boost-trunk/tools/build/v2/doc/

I was unable to find a good definition of a module.  The
following
grep:

cd
/home/evansl/prog_dev/boost-svn/ro/boost-trunk/tools/build/v
2/doc/src/
find . -name *.xml -exec grep module {} ; -ls|grep -e 'r--
'
8195376   56 -rw-r--r--   1 evansl   evansl      51254 Aug 
4 13:50 
./advanced.xml
8195377   40 -rw-r--r--   1 evansl   evansl      36951 Aug 
4 13:50 
./extending.xml
8195374   28 -rw-r--r--   1 evansl   evansl      25383 Aug 
4 13:50 
./architecture.xml
8195387   80 -rw-r--r--   1 evansl   evansl      77228 Aug 
4 13:50 
./reference.xml
8195382   16 -rw-r--r--   1 evansl   evansl      15368 Aug 
4 13:50 
./faq.xml
8195379    8 -rw-r--r--   1 evansl   evansl       4587 Aug 
4 13:50 
./v1_vs_v2.xml

shows where I looked.  The closest I found was in
extending.xml which
contained:

   For example, if you create a module
   <filename>obfuscate.jam</filename>
containing:

and in archecture.xml which contained:

   <listitem><para>Metatargets (see the
"targets.jam" module) represent
   ...
   <listitem><para>Virtual targets (see the
"virtual-targets.jam"
     module) correspond to the atomic things which can be
updated --

However, these only *suggest* that:

   A module is a file with extension .jam .

... and, of course, containing build.v2 code. Is that
right?

Apparently someone else noticed this problem of "no
module definition"
because extending.xml contains:

     for loading and configuring extensions.  To make it
work, your module
     <!-- "module" hasn't been defined yet. 
Furthermore you haven't
          said anything about where that module file must
be
          placed. -->

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

On 08/04/2007 09:30 AM, Vladimir Prus wrote:
> Larry Evans wrote:
> 
>> On 08/03/2007 01:23 PM, Larry Evans wrote:
>> [snip]
>>> * question 2
>>>
>>> The following is from gcc.jam:
>>> <-------- cut here ---------
>>> actions link bind LIBRARIES
>>> {
>>>      "$(CONFIG_COMMAND)"
-L"$(LINKPATH)"
>>>
-Wl,$(RPATH_OPTION:E=-R)$(SPACE)-Wl,"$(RPATH)"
>>>
-Wl,-rpath-link$(SPACE)-Wl,"$(RPATH_LINK)" -o
"$(<)" $(START-GROUP)
>>> "$(>)" "$(LIBRARIES)"
-l$(FINDLIBS-ST) -l$(FINDLIBS-SA) $(END-GROUP)
>>> $(OPTIONS) $(USER_OPTIONS)
>>> #the above appears all on one line in my
editor.
>>> }
>>>
>>>  >-------- cut here ---------
>>>
>>> What variable values are available in the
actions body?  Was the
[snip]
> A rule can use the following variables:
> 
> 1. Variables globally set in the module an action is
in.
> 2. A variable set "on target"
> 
> On Boost.Build, the "on target" variables to
set are described via
> the 'flags' rule. So, this line from gcc.jam:
> 
>         flags $(toolset).link RPATH_LINK $(condition) :
<xdll-path> : unchecked ;
> 
> makes RPATH_LINK available in the 'link' action.
[snip]
A still confused.  The attachments show my attempt at using
variables in
the action of a cpreproc rule.  What I really want is the
variable
storing the include paths; however, I tried cut and pasting
the 
RPATH_LINK from gcc.jam to get it to work; however, as the
output shows,
it's not working.  What am I doing wrong?

TIA.

BTW, in the compile.out attachment, the lines starting with
gcc.jam: are
from some debug prints I added to gcc.jam:

     case gnu :
         {
         # Strip the binary when no debugging is needed.
         # We use --strip-all flag as opposed to -s since
icc
         # (intel's compiler) is generally option-compatible
with
         # and inherits from gcc toolset, but does not
support -s
         flags $(toolset).link OPTIONS
$(condition)/<debug-symbols>off : 
-Wl,--strip-all
           : unchecked ;
         ECHO
"gcc.jam:init-link-flags:toolset,condition= $(toolset)
, 
$(condition)" ;
         flags $(toolset).link RPATH $(condition) :
<dll-path> : unchecked ;

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build