fix(doc): broken links

doc/local-playbook.yml

@@ -70,6 +70,11 @@ asciidoc:
     - '@cppalliance/asciidoctor-boost-links'
     - '@asciidoctor/tabs'
 
+runtime:
+  log:
+    level: warn
+    failure_level: warn
+
 # Libraries that support Antora should be included here
 content:
   sources:

doc/modules/ROOT/pages/reference/back-end-headers.adoc

@@ -35,7 +35,7 @@ ShallowHistory. Default is NoHistory.
 The trade-off performance / compile-time. There are two predefined
 policies, favor_runtime_speed and favor_compile_time. Default is
 favor_runtime_speed, best performance, longer compile-time. See
-link:#backend-tradeof-rt-ct[the backend].
+xref:tutorial/back-end.adoc#backend-tradeof-rt-ct[the backend].
 
 [[methods]]
 
@@ -47,7 +47,7 @@ link:#backend-tradeof-rt-ct[the backend].
 
 The start methods must be called before any call to process_event. It
 activates the entry action of the initial state(s). This allows you to
-choose when a state machine can start. See link:#backend-start[backend].
+choose when a state machine can start. See xref:tutorial/back-end.adoc#backend-start[backend].
 
 void start
 

doc/modules/ROOT/pages/tutorial.adoc

@@ -2,24 +2,16 @@
 
 = Tutorial
 
-MSM is divided between front-ends and back-ends. At the moment, there is
-just one back-end. On the front-end side, you will find three of them
-which are as many state machine description languages, with many more
+MSM is divided between front-ends and back-ends.
+You will find four front-ends, which are as many state machine description languages, with many more
 possible. For potential language writers, this document contains a
-link:#internals-front-back-interface[description of the interface
-between front-end and back-end].
+xref:internals.adoc#internals-front-back-interface[description of the interface between front-end and back-end].
 
 The first front-end is an adaptation of the example provided in the
 http://boostpro.com/mplbook[MPL book] with actions defined as pointers
 to state or state machine methods. The second one is based on functors.
-The third, eUML (embedded UML) is an experimental language based on
+The third, eUML (embedded UML) is a deprecated language based on
 Boost.Proto and Boost.Typeof and hiding most of the metaprogramming to
-increase readability. Both eUML and the functor front-end also offer a
-functional library (a bit like Boost.Phoenix) for use as action language
-(UML defining none).
-
-// * xref:tutorial/basic-front-end.adoc[Basic front-end]
-// * xref:tutorial/functor-front-end.adoc[Functor front-end]
-// * xref:tutorial/puml-front-end.adoc[PUML front-end (C++20, experimental)]
-// * xref:tutorial/euml-front-end.adoc[eUML front-end (deprecated)]
-// * xref:tutorial/back-end.adoc[Back-end]
+increase readability. It is superseded by an experimental PUML front-end that allows a more intuitive syntax.
+Both eUML and the functor front-end also offer a functional library (a bit like Boost.Phoenix)
+for use as action language (UML defining none).

doc/modules/ROOT/pages/tutorial/back-end.adoc

@@ -464,7 +464,7 @@ cases:
 * many transition conflicts
 * submachines
 
-The back-end `msm::back11::state_machine` has a policy argument (first
+The back-end `msm::back::state_machine` has a policy argument (first
 is the front-end, then the history policy) defaulting to
 `favor_runtime_speed`. To switch to `favor_compile_time`, which is
 declared in `<msm/back/favor_compile_time.hpp>`, you need to:
@@ -491,9 +491,9 @@ Independently, transition conflicts resolution will also be much faster.
 
 This policy uses boost.any behind the hood, which means that we will
 lose a feature which MSM offers with the default policy,
-link:#event-hierarchy[event hierarchy]. The following example takes our
-iPod example and speeds up compile-time by using this technique. We
-have:
+xref:tutorial/basic-front-end.adoc#event-hierarchy[event hierarchy].
+The following example takes our iPod example and speeds up compile-time 
+by using this technique. We have:
 
 * xref:attachment$iPod_distributed/iPod.cpp[our main state machine and
 main function]

doc/modules/ROOT/pages/tutorial/basic-front-end.adoc

@@ -317,9 +317,9 @@ state machine just after creation. The start method will initiate the
 state machine, meaning it will activate the initial state, which means
 in turn that the initial state's entry behavior will be called. The
 reason why we need this will be explained in the
-link:#backend-start[back-end part]. After a call to start, the state
-machine is ready to process events. The same way, calling `stop()` will
-cause the last exit actions to be called.
+xref:tutorial/back-end.adoc#backend-start[back-end part].
+After a call to start, the state machine is ready to process events.
+The same way, calling `stop()` will cause the last exit actions to be called.
 
 [[defining-a-submachine]]
 
@@ -577,7 +577,7 @@ replaced by a History symbol (the H inside a circle).
 As explained in the `small UML tutorial`, History is a good concept with
 a not completely satisfying specification. MSM kept the concept but not
 the specification and goes another way by making this a policy and you
-can add your own history types (the link:#history-interface[reference]
+can add your own history types (the xref:reference/back-end-headers.adoc#history-interface[reference]
 explains what needs to be done). Furthermore, History is a backend
 policy. This allows you to reuse the same state machine definition with
 different history policies in different contexts.
@@ -1133,8 +1133,11 @@ if (p.template is_flag_active<CDLoaded>()) ...
 
 The following diagram displays the flag situation in the tutorial.
 
-image:FlagsTutorial.jpg[image] ### [[event-hierarchy]]Event
-Hierarchy
+image:FlagsTutorial.jpg[image]
+
+[[event-hierarchy]]
+
+== Event Hierarchy
 
 There are cases where one needs transitions based on categories of
 events. An example is text parsing. Let's say you want to parse a string

doc/modules/ROOT/pages/tutorial/euml-front-end.adoc

@@ -379,7 +379,7 @@ machine where the transition table, initial state, entry and exit
 actions are defined. Furthermore, attributes (read further on), flags,
 deferred events and configuration capabilities (no message queue / no
 exception catching) are added and a non-default base state (see the
-link:#backend-base-state[back-end description]) is defined.
+xref:tutorial/back-end.adoc#backend-base-state[back-end description]) is defined.
 
 For example, a minimum state machine could be defined as:
 
@@ -963,7 +963,7 @@ a functional programming paradigm, for example:
 
 In a nutshell, almost every STL method or algorithm is matched by a
 corresponding functor, which can then be used in the transition table or
-state actions. The link:#Reference-begin[reference] lists all eUML
+state actions. The xref:reference/euml-operators-and-basic-helpers.adoc[reference] lists all eUML
 functions and the underlying functor (so that this possibility is not
 reserved to eUML but also to the functor-based front-end). The file
 structure of this Phoenix-like library matches the one of Boost.Phoenix.