From: David Abrahams (dave_at_[hidden])
Date: 2002-11-11 17:55:28
Whatever's going on in this rule, it's _way_* too tricky. If it _were_
important to do something this tricky, it's at least way
.args = 5 6 7 8 9 ;
# Creates a main target alternative of type 'class-name'. The ctor will be
# passed 'target-name', 'project' and all trailing arguments.
# If 'requirements-pos' and 'default-build-pos' are specified, the corresponding
# trailing arguments will be specially processed.
rule main-target-alternative ( target-name project class-name
: requirements-pos ? : use-requirements-pos ? : default-build-pos ?
: * )
for local i in $(.args)
a$(i) = $($(i)) ;
local real-pos = $(.args[$(requirements-pos)]) ;
local real-pos2 = $(.args[$(use-requirements-pos)]) ;
local project-requirements = [ project.attribute $(project) requirements ] ;
local project-use-requirements = [ project.attribute $(project) use-requirements ] ;
What the heck is "will be specially processed" supposed to indicate to
Also, the way this rule is invoked is extremely tricky as well:
rule main-target-rule ( name : sources * : requirements * : default-build *
: use-requirements * )
# First find required target type, which is equal to the name used
# to invoke us.
local bt = [ BACKTRACE 1 ] ;
local type = $(bt) ;
targets.main-target-alternative $(name) [ CALLER_MODULE ] typed-target : 3 : 5 : 4
: $(type:U) : $(sources) : $(requirements) : $(default-build) : $(use-requirements)
Where does "type" come from? How do we get here?
This kind of reaching back into the call stack always needs some extra
comments to describe what's actually going on.
Something should state explicitly that types and main target rule
names have a one-to-one uppercase/lowercase relationship.
-- David Abrahams dave_at_[hidden] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution
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