Update of /cvsroot/boost/boost/tools/build/v2/build
In directory sc8-pr-cvs3.sourceforge.net:/tmp/cvs-serv5206
Modified Files:
targets.jam
Log Message:
Handle indirect conditional properties in usage requirements
Index: targets.jam
===================================================================
RCS file: /cvsroot/boost/boost/tools/build/v2/build/targets.jam,v
retrieving revision 1.205
retrieving revision 1.206
diff -u -d -r1.205 -r1.206
--- targets.jam 18 Nov 2006 18:34:42 -0000 1.205
+++ targets.jam 22 Nov 2006 09:35:06 -0000 1.206
@@ -914,30 +914,38 @@
}
result = [ $($(key)).add-raw $(free) ] ;
}
-
-rule common-properties2 ( build-request requirements )
-{
- # This guarantees that default properties are present
- # in result, unless they are overrided by some requirement.
- # FIXME: There is possibility that we've added <foo>bar, which is composite
- # and expands to <foo2>bar2, but default value of <foo2> is not bar2,
- # in which case it's not clear what to do.
+
+# Given 'context' -- a set of already present properties, and 'requirements',
+# decide which extra properties should be applied to 'context'.
+# For conditional requirements, this means evaluating condition. For
+# indirect conditional requirements, this means calling a rule. Ordinary
+# requirements are always applied.
+#
+# Handles situation where evaluating one conditional requirements affects
+# condition of another conditional requirements, for example:
+#
+# <toolset>gcc:<variant>release <variant>release:<define>RELEASE
+#
+# If 'what' is 'refined' returns context refined with new requirements.
+# If 'what' is 'added' returns just the requirements that must be applied.
+rule evaluate-requirements ( requirements : context : what )
+{
+ # Apply non-conditional requirements.
+ # It's possible that that further conditional requirement change
+ # a value set by non-conditional requirements. For example:
+ #
+ # exe a : a.cpp : <threading>single <toolset>foo:<threading>multi ;
#
- build-request = [ $(build-request).add-defaults ] ;
- # Featured added by 'add-default' can be composite and expand
- # to features without default values -- so they are not added yet.
- # It could be clearer/faster to expand only newly added properties
- # but that's not critical.
- build-request = [ $(build-request).expand ] ;
+ # I'm not sure if this should be an error, or not, especially given that
+ #
+ # <threading>single
+ #
+ # might come from project's requirements.
- # Apply non-conditional requirements.
- # There's a slight bug here: it's possible that conditional
- # requirement change a value set by non-conditional requirements. This
- # should be error, but we don't detect it yet.
+ local unconditional = [ feature.expand [ $(requirements).non-conditional ]
] ;
- local raw = [ $(build-request).raw ] ;
- raw = [ property.refine $(raw) :
- [ feature.expand [ $(requirements).non-conditional ] ] ] ;
+ local raw = [ $(context).raw ] ;
+ raw = [ property.refine $(raw) : $(unconditional) ] ;
# We've collected properties that surely must be present in common
# properties. We now try to figure out what other properties
@@ -954,7 +962,8 @@
local count = $(conditionals)
[ $(requirements).get <conditional> ]
and-once-more ;
- local prev ;
+
+ local added-requirements ;
local current = $(raw) ;
@@ -979,7 +988,7 @@
e += [ indirect.call $(i) $(current) ] ;
}
- if $(e) = $(prev)
+ if $(e) = $(added-requirements)
{
# If we got the same result, we've found final properties.
count = ;
@@ -987,11 +996,11 @@
}
else
{
- # Oops, results of evaluation of conditionals has changes
+ # Oops, results of evaluation of conditionals has changed.
# Also 'current' contains leftover from previous evaluation.
# Recompute 'current' using initial properties and conditional
# requirements.
- prev = $(e) ;
+ added-requirements = $(e) ;
current = [ property.refine $(raw) : [ feature.expand $(e) ] ] ;
}
count = $(count[2-]) ;
@@ -1001,8 +1010,39 @@
errors.error "Can't evaluate conditional properties " $(conditionals) ;
}
+
+ if $(what) = added
+ {
+ return [ property-set.create $(unconditional) $(added-requirements) ] ;
+ }
+ else if $(what) = refined
+ {
+ return [ property-set.create $(current) ] ;
+ }
+ else
+ {
+ errors.error "Invalid value of the 'what' parameter" ;
+ }
+}
+
- return [ property-set.create $(current) ] ;
+rule common-properties2 ( build-request requirements )
+{
+ # This guarantees that default properties are present
+ # in result, unless they are overrided by some requirement.
+ # FIXME: There is possibility that we've added <foo>bar, which is composite
+ # and expands to <foo2>bar2, but default value of <foo2> is not bar2,
+ # in which case it's not clear what to do.
+ #
+ build-request = [ $(build-request).add-defaults ] ;
+ # Featured added by 'add-default' can be composite and expand
+ # to features without default values -- so they are not added yet.
+ # It could be clearer/faster to expand only newly added properties
+ # but that's not critical.
+ build-request = [ $(build-request).expand ] ;
+
+ return [ evaluate-requirements $(requirements)
+ : $(build-request) : refined ] ;
}
# Implements the most standard way of constructing main target
@@ -1244,8 +1284,10 @@
rule compute-usage-requirements ( subvariant )
{
local rproperties = [ $(subvariant).build-properties ] ;
- xusage-requirements = [
$(self.usage-requirements).evaluate-conditionals
- $(rproperties) ] ;
+ xusage-requirements = [ targets.evaluate-requirements
+ $(self.usage-requirements)
+ : $(rproperties)
+ : added ] ;
# We generate all dependency properties and add them,
# as well as their usage requirements, to result.
@@ -1433,10 +1475,15 @@
{
local loc = [ $(project).get location ] ;
local project-usage-requirements = [ $(project).get usage-requirements ] ;
-
- local usage-requirements = [ property-set.create
- [ property.translate-paths $(specification) : $(loc) ] ] ;
+ # We don't use 'refine-from-user-input' because I'm not sure if:
+ # - removing of parent's usage requirements makes sense
+ # - refining of usage requirements is not needed, since usage requirements
+ # are always free.
+ local usage-requirements = [ property-set.create-from-user-input
+ $(specification)
+ : [ $(project).project-module ] [ $(project).get location ] ] ;
+
return [ $(project-usage-requirements).add $(usage-requirements) ] ;
}
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Boost-cvs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/boost-cvs
