Complete documentation update (#599)

Signed-off-by: Olga Malysheva <[email protected]>

doc/main/conf.py

@@ -25,7 +25,7 @@
 
 # -- Project information -----------------------------------------------------
 
-if BUILD_TYPE == 'oneapi':
+if BUILD_TYPE == 'oneapi' or BUILD_TYPE == 'dita':
     project = u'Intel® oneAPI Threading Building Blocks (oneTBB)'
 else:
     project = u'oneAPI Threading Building Blocks (oneTBB)'
@@ -90,7 +90,7 @@
 # Syntax highlighting for the :: directive
 highlight_language = 'cpp' 
 
-if BUILD_TYPE == 'oneapi':
+if BUILD_TYPE == 'oneapi' or BUILD_TYPE == 'dita':
     rst_prolog = """
 .. |full_name| replace:: Intel\ |reg|\  oneAPI Threading Building Blocks (oneTBB)
 .. |short_name| replace:: oneTBB
@@ -120,7 +120,7 @@
 # further.  For a list of options available for each theme, see the
 # documentation.
 #
-if BUILD_TYPE == 'oneapi':
+if BUILD_TYPE == 'oneapi' or BUILD_TYPE == 'dita':
     html_theme = 'sphinx_rtd_theme'
 else:
     html_theme = 'sphinx_book_theme'
@@ -140,7 +140,7 @@
 # so a file named "default.css" will overwrite the builtin "default.css".
 html_static_path = ['_static']
 
-if BUILD_TYPE == 'oneapi':
+if BUILD_TYPE == 'oneapi'  or BUILD_TYPE == 'dita':
     html_context = {
         'css_files': [
             '_static/theme_overrides.css',  # override wide tables in RTD theme

doc/main/tbb_userguide/Data_Flow_Graph.rst

@@ -191,8 +191,7 @@ This final implementation has all of the nodes and edges from the
 much advantage in using an ``input_node`` over an explicit loop. But,
 because an ``input_node`` is able to react to the behavior of downstream
 nodes, it can limit memory use in more complex graphs. For more
-information, see `Creating a Token-Based
-System <create_token_based_system.html#create_token_based_system>`__
+information, see:ref:`create_token_based_system` .
 
 
 .. |image0| image:: Images/flow_graph.jpg

doc/main/tbb_userguide/destroy_graphs_outside_main_thread.rst

@@ -9,8 +9,7 @@ You may not always want to block the main application thread by calling
 wait_for_all(). However, it is safest to call wait_for_all on a graph
 before destroying it. A common solution is to enqueue a task to build
 and wait for the graph to complete. For example, assume you really do
-not want to call a wait_for_all in the example from `Always Use
-wait_for_all() <always_use_wait_for_all.html#always_use_wait4all>`__,
+not want to call a wait_for_all in the example from :ref:`always_use_wait_for_all`,
 Instead you can enqueue a task that creates the graph and waits for it:
 
 

doc/main/tbb_userguide/use_graph_reset.rst

@@ -7,8 +7,7 @@ Use graph::reset() to Reset a Canceled Graph
 When a graph execution is canceled either because of an unhandled
 exception or because its task_group_context is canceled explicitly, the
 graph and its nodes may be left in an indeterminate state. For example,
-in the code samples shown in `Cancel a Graph
-Explicitly <cancel_a_graph.html#cancel_a_graph>`__ the input 2 may be
+in the code samples shown in :ref:`cancel_a_graph` the input 2 may be
 left in a buffer. But even beyond remnants in the buffers, there are
 other optimizations performed during the execution of a flow graph that
 can leave its nodes and edges in an indeterminate state. If you want to

doc/main/tbb_userguide/use_input_node.rst

@@ -29,8 +29,7 @@ All ``input_node`` objects are constructed in the inactive state and usually
 activated after the entire flow graph is constructed.
 
 
-For example, you can use the code in `Data Flow
-Graph <Data_Flow_Graph.html#Data_Flow_Graph>`__. In that implementation,
+For example, you can use the code in :ref:`Data_Flow_Graph`. In that implementation,
 the ``input_node`` is constructed in the inactive state and activated after
 all other edges are made: