Fix phoenix links

doc/faq.qbk

@@ -113,9 +113,9 @@ Again, don't use any of the header files underneath the boost/spirit/home
 directory directly, always include files from the boost/spirit/include 
 directory.
 
-The last bit missing is __boost_phoenix__ (which currently still lives under the 
+The last bit missing is __phoenix__ (which currently still lives under the 
 Spirit umbrella, but already has been accepted as a Boost library, so it will 
-move away). __boost_phoenix__ is a library allowing to write functional style C++, 
+move away). __phoenix__ is a library allowing to write functional style C++, 
 which is interesting in itself, but as it initially has been developed for 
 Spirit, it is nicely integrated and very useful when it comes to writing 
 semantic actions. I think using the boost/spirit/include/phoenix_... headers 

doc/karma/auxiliary.qbk

@@ -389,7 +389,7 @@ not defined in __generator_concept__.
 
 [table
     [[Expression]       [Semantics]]
-    [[`fg`]             [The __boost_phoenix__ function object `fg` will be 
+    [[`fg`]             [The __phoenix__ function object `fg` will be 
                          invoked at generate time. It is expected to return a
                          generator instance. This generator is then invoked
                          in order to generate the output. This generator will
@@ -399,7 +399,7 @@ not defined in __generator_concept__.
     [[`lazy(fg)`]       [The function or function object will be invoked at 
                          generate time. It is expected to return a generator 
                          instance  (note this version of `lazy` does not 
-                         require `fg` to be a __boost_phoenix__ function 
+                         require `fg` to be a __phoenix__ function 
                          object). This generator is then invoked in order to 
                          generate the output. This generator will succeed as 
                          long as the invoked generated succeeds as well (except 

doc/karma/complex.qbk

@@ -15,7 +15,7 @@ are the real and imaginary parts of the complex number) or as a simple `real`
 if the imaginary part happens to be equal to zero. This example will highlight
 the power of __karma__ allowing to combine compile time definition of 
 formatting rules with runtime based decisions which of the rules to apply. 
-Also this time, we're using __boost_phoenix__ to do the semantic actions.
+Also this time, we're using __phoenix__ to do the semantic actions.
 
 Our goal is to allow for two different output formats to be applied depending 
 on whether the imaginary part of the complex number is zero or not. Let's write

doc/karma/quick_reference.qbk

@@ -660,12 +660,12 @@ For more information see __karma_actions__.
 [/////////////////////////////////////////////////////////////////////////////]
 [section Phoenix]
 
-__boost_phoenix__ makes it easier to attach semantic actions. You just
+__phoenix__ makes it easier to attach semantic actions. You just
 inline your lambda expressions:
 
     g[phoenix-lambda-expression]
 
-__karma__ provides some __boost_phoenix__ placeholders to access important
+__karma__ provides some __phoenix__ placeholders to access important
 information from the `Attrib` and `Context` that are otherwise fiddly to extract.
 
 [variablelist Spirit.Karma specific Phoenix placeholders

doc/lex/lexer_quickstart2.qbk

@@ -24,11 +24,11 @@ see here: [@../../example/lex/word_count_lexer.cpp word_count_lexer.cpp]).
 [heading Prerequisites]
 
 In addition to the only required `#include` specific to /Spirit.Lex/ this 
-example needs to include a couple of header files from the __boost_phoenix__ 
+example needs to include a couple of header files from the __phoenix__ 
 library. This example shows how to attach functors to token definitions, which 
 could be done using any type of C++ technique resulting in a callable object.
-Using __boost_phoenix__ for this task simplifies things and avoids adding 
+Using __phoenix__ for this task simplifies things and avoids adding 
-dependencies to other libraries (__boost_phoenix__ is already in use for 
+dependencies to other libraries (__phoenix__ is already in use for 
 __spirit__ anyway).
 
 [wcl_includes]
@@ -59,7 +59,7 @@ brackets will be executed whenever the corresponding token has been matched by
 the lexical analyzer. This is very similar to __flex__, where the action code 
 associated with a token definition gets executed after the recognition of a
 matching input sequence. The code above uses function objects constructed using 
-__boost_phoenix__, but it is possible to insert any C++ function or function object 
+__phoenix__, but it is possible to insert any C++ function or function object 
 as long as it exposes the proper interface. For more details on please refer 
 to the section __sec_lex_semactions__. 
 

doc/lex/lexer_quickstart3.qbk

@@ -41,11 +41,11 @@ of semantic actions of a parser (for the full example code see here:
 
 This example uses two of the __spirit__ library components: __lex__ and __qi__,
 consequently we have to `#include` the corresponding header files. Again, we
-need to include a couple of header files from the __boost_phoenix__ library. This 
+need to include a couple of header files from the __phoenix__ library. This 
 example shows how to attach functors to parser components, which 
 could be done using any type of C++ technique resulting in a callable object.
-Using __boost_phoenix__ for this task simplifies things and avoids adding 
+Using __phoenix__ for this task simplifies things and avoids adding 
-dependencies to other libraries (__boost_phoenix__ is already in use for 
+dependencies to other libraries (__phoenix__ is already in use for 
 __spirit__ anyway).
 
 [wcp_includes]

doc/lex/lexer_semantic_actions.qbk

@@ -116,7 +116,7 @@ gives an overview and a short description of the available functionality.
 
 Even if it is possible to write your own function object implementations (i.e. 
 using Boost.Lambda or Boost.Bind), the preferred way of defining lexer semantic 
-actions is to use __boost_phoenix__. In this case you can access the parameters 
+actions is to use __phoenix__. In this case you can access the parameters 
 described above by using the predefined __spirit__ placeholders: 
 
 [table Predefined Phoenix placeholders for lexer semantic actions
@@ -153,7 +153,7 @@ described above by using the predefined __spirit__ placeholders:
 ]
 
 The context object passed as the last parameter to any lexer semantic action is 
-not directly accessible while using __boost_phoenix__ expressions. We rather provide
+not directly accessible while using __phoenix__ expressions. We rather provide
 predefined Phoenix functions allowing to invoke the different support functions
 as mentioned above. The following table lists the available support functions 
 and describes their functionality:

doc/lex/quick_reference.qbk

@@ -88,12 +88,12 @@ For more information see __lex_actions__.
 [/////////////////////////////////////////////////////////////////////////////]
 [section Phoenix]
 
-__boost_phoenix__ makes it easier to attach semantic actions. You just
+__phoenix__ makes it easier to attach semantic actions. You just
 inline your lambda expressions:
 
     l[phoenix-lambda-expression]
 
-__lex__ provides some __boost_phoenix__ placeholders to access important
+__lex__ provides some __phoenix__ placeholders to access important
 information from the `Context` that are otherwise difficult to extract.
 
 [variablelist Spirit.Lex specific Phoenix placeholders

doc/notes/porting_from_1_8.qbk

@@ -50,7 +50,7 @@ refer to the corresponding reference documentation of this component.
 [table
     [[Include file in /Spirit.Classic/] [Include file in /Spirit.Qi/]]
     [[`classic.hpp`]                    [`qi.hpp`]]
-    [[`classic_actor.hpp`]              [none, use __boost_phoenix__ for writing semantic actions]]
+    [[`classic_actor.hpp`]              [none, use __phoenix__ for writing semantic actions]]
     [[`classic_attribute.hpp`]          [none, use local variables for rules instead of closures, 
                                          the primitives parsers now directly support lazy
                                          parameterization]]

doc/preface.qbk

@@ -109,7 +109,7 @@ Another library had to be written: __fusion__. Fusion sits between MPL
 and STL --between compile time and runtime -- mapping types to values.
 Fusion is a direct descendant of both MPL and __boost_tuples__. Fusion
 is now a full-fledged __boost__ library. __phoenix__ also had to be
-beefed up to support Spirit V2. The result is __boost_phoenix__. Last
+beefed up to support Spirit V2. The result is __phoenix__. Last
 but not least, Spirit V2 uses an __exprtemplates__ library called
 __boost_proto__.
 

doc/qi/quick_reference.qbk

@@ -486,12 +486,12 @@ For more detailed information about semantic actions see:
 [endsect]
 [section Phoenix]
 
-__boost_phoenix__ makes it easier to attach semantic actions. You just
+__phoenix__ makes it easier to attach semantic actions. You just
 inline your lambda expressions:
 
     p[phoenix-lambda-expression]
 
-Spirit.Qi provides some __boost_phoenix__ placeholders to important
+Spirit.Qi provides some __phoenix__ placeholders to important
 information from the `Attrib` and `Context` that are otherwise fiddly to extract.
 
 [variablelist Spirit.Qi specific Phoenix placeholders

doc/spirit2.qbk

@@ -27,8 +27,7 @@
 
 [def __spirit__                 [@http://boost-spirit.com Spirit]]
 [def __spirit_list__            [@http://www.nabble.com/The-Spirit-Parser-Library-f3430.html Spirit General List]]
-[def __phoenix__                [@../../phoenix/doc/html/index.html Phoenix]]
+[def __phoenix__                [@boost:/libs/phoenix/doc/html/index.html Boost.Phoenix]]
-[def __boost_phoenix__          [@boost:/libs/phoenix/doc/html/index.html Boost.Phoenix]]
 [def __fusion__                 [@boost:/libs/fusion/doc/html/index.html Boost.Fusion]]
 [def __mpl__                    [@http://www.boost.org/libs/mpl/index.html Boost.Mpl]]
 [def __stl__                    [@http://www.sgi.com/tech/stl/ STL]]

doc/what_s_new.qbk

@@ -81,13 +81,13 @@
 
 [heading What's changed in __qi__ and __karma__ from V2.4.2 (Boost V1.46.0) to V2.5 (Boost V1.47.0)]
 
-This version of __spirit__ now supports the new version of __boost_phoenix__ (V3),
+This version of __spirit__ now supports the new version of __phoenix__ (V3),
 which has been released as part of Boost V1.47. Please note that this support
 is purely preliminary and should not be considered production quality. The
 reason why we are releasing this now is to enable people who want to use the
-new version of __boost_phoenix__ in their code to do so without any conflicts with
+new version of __phoenix__ in their code to do so without any conflicts with
 existing code using __spirit__. Generally, no __spirit__ code needs to be
-changed. To activate the use of __boost_phoenix__ V3 for __spirit__ you need to
+changed. To activate the use of __phoenix__ V3 for __spirit__ you need to
 define the following preprocessor constant for your builds (before including
 any of Spirit's include files):
 

repository/doc/spirit2_repository.qbk

@@ -23,8 +23,7 @@
 
 [def __spirit__                 [@http://boost-spirit.com Spirit]]
 [def __spirit_list__            [@http://www.nabble.com/The-Spirit-Parser-Library-f3430.html Spirit General List]]
-[def __phoenix__                [@../../phoenix/doc/html/index.html Phoenix]]
+[def __phoenix__                [@boost:/libs/phoenix/doc/html/index.html Boost.Phoenix]]
-[def __boost_phoenix__               [@../../phoenix/doc/html/index.html Phoenix2]]
 [def __fusion__                 [@http://spirit.sourceforge.net/dl_more/fusion_v2/libs/fusion/doc/html/index.html Fusion]]
 [def __mpl__                    [@http://www.boost.org/libs/mpl/index.html MPL]]
 [def __boost__                  [@http://www.boost.org/ Boost]]