[master] c65d257ab man: Document built-in subs in a reference manual

Nils Goroll nils.goroll at uplex.de
Mon May 15 13:27:06 UTC 2023


commit c65d257ab9e7cee5a77a35aa0128f9fce701db1c
Author: Walid Boudebouda <walid.boudebouda at gmail.com>
Date:   Tue Mar 28 16:10:56 2023 +0200

    man: Document built-in subs in a reference manual
    
    Instead of documenting built-in subroutines in the user guide, a new
    vcl-step(7) manual is added. It is structured with a vcl-step.rst file
    that includes a vcl_step.rst file containing the actual list of steps.
    
    This is similar to how the vcl-var(7) manual is constructed to later
    make it authoritative.

diff --git a/doc/sphinx/conf.py.in b/doc/sphinx/conf.py.in
index 30c527a50..a0bb5d40b 100644
--- a/doc/sphinx/conf.py.in
+++ b/doc/sphinx/conf.py.in
@@ -64,7 +64,7 @@ release = '@VERSION@'
 
 # List of directories, relative to source directory, that shouldn't be searched
 # for source files.
-exclude_patterns = ['build','include/*.rst','reference/vcl_var.rst']
+exclude_patterns = ['build','include/*.rst','reference/vcl_*.rst']
 
 # The reST default role (used for this markup: `text`) to use for all documents.
 #default_role = None
diff --git a/doc/sphinx/reference/index.rst b/doc/sphinx/reference/index.rst
index cb50ea6ff..8eec67414 100644
--- a/doc/sphinx/reference/index.rst
+++ b/doc/sphinx/reference/index.rst
@@ -19,6 +19,7 @@ The VCL language
 
 	VCL - The Varnish Configuration Language <vcl>
 	VCL Variables <vcl-var>
+	VCL Steps <vcl-step>
 	VCL backend configuration <vcl-backend>
 	VCL backend health probe <vcl-probe>
 	states.rst
diff --git a/doc/sphinx/reference/states.rst b/doc/sphinx/reference/states.rst
index b816c25d7..2a4cbbacc 100644
--- a/doc/sphinx/reference/states.rst
+++ b/doc/sphinx/reference/states.rst
@@ -18,7 +18,7 @@ state machines. Whenever a state is entered, a C function is called,
 which in turn calls the appropriate Varnish core code functions to
 process the request or response at this stage. For most states, core
 code also calls into a state-specific function compiled from VCL, a
-VCL subroutine (see :ref:`vcl-built-in-subs` ).
+VCL subroutine (see :ref:`vcl_steps`).
 
 As a general guideline, core code aims to prepare objects accessible
 from VCL with good defaults for the most common cases before calling
diff --git a/doc/sphinx/reference/vcl-step.rst b/doc/sphinx/reference/vcl-step.rst
new file mode 100644
index 000000000..011e84e00
--- /dev/null
+++ b/doc/sphinx/reference/vcl-step.rst
@@ -0,0 +1,63 @@
+..
+	Copyright (c) 2013-2021 Varnish Software AS
+	SPDX-License-Identifier: BSD-2-Clause
+	See LICENSE file for full text of license
+
+
+.. role:: ref(emphasis)
+
+.. _vcl-steps(7):
+
+=========
+VCL-steps
+=========
+
+--------------------
+Built-in subroutines
+--------------------
+
+:Manual section: 7
+
+
+DESCRIPTION
+===========
+
+Various built-in subroutines are called during processing of client
+and backend requests as well as upon ``vcl.load`` and ``vcl.discard``.
+
+See :ref:`reference-states` for a detailed graphical overview of the
+states and how they relate to core code functions and VCL subroutines.
+
+Built-in subroutines always terminate with a ``return (<action>)``,
+where ``<action>`` determines how processing continues in the request
+processing state machine.
+
+The behaviour of actions is identical or at least similar across
+subroutines, so differences are only documented where relevant.
+
+Common actions are documented in
+:ref:`user-guide-vcl_actions`. Actions specific to only one or some
+subroutines are documented herein.
+
+A default behavior is provided for all :ref:`reference-states` in the
+:ref:`vcl-built-in-code` code.
+
+
+.. include:: vcl_step.rst
+
+
+
+SEE ALSO
+========
+
+* :ref:`varnishd(1)`
+* :ref:`vcl(7)`
+
+COPYRIGHT
+=========
+
+This document is licensed under the same license as Varnish
+itself. See LICENSE for details.
+
+* Copyright (c) 2006 Verdens Gang AS
+* Copyright (c) 2006-2021 Varnish Software AS
diff --git a/doc/sphinx/reference/vcl.rst b/doc/sphinx/reference/vcl.rst
index 3770dc626..5143f0ff0 100644
--- a/doc/sphinx/reference/vcl.rst
+++ b/doc/sphinx/reference/vcl.rst
@@ -445,6 +445,7 @@ SEE ALSO
 * :ref:`varnishd(1)`
 * :ref:`vcl-backend(7)`
 * :ref:`vcl-probe(7)`
+* :ref:`vcl-steps(7)`
 * :ref:`vcl-var(7)`
 * :ref:`vmod_directors(3)`
 * :ref:`vmod_std(3)`
diff --git a/doc/sphinx/users-guide/vcl-built-in-subs.rst b/doc/sphinx/reference/vcl_step.rst
similarity index 52%
rename from doc/sphinx/users-guide/vcl-built-in-subs.rst
rename to doc/sphinx/reference/vcl_step.rst
index 3d6b67f04..30d946a9a 100644
--- a/doc/sphinx/users-guide/vcl-built-in-subs.rst
+++ b/doc/sphinx/reference/vcl_step.rst
@@ -1,36 +1,11 @@
-..
-	Copyright (c) 2013-2021 Varnish Software AS
-	SPDX-License-Identifier: BSD-2-Clause
-	See LICENSE file for full text of license
 
-.. _vcl-built-in-subs:
+.. _vcl_steps:
 
-Built-in subroutines
-====================
+VCL Steps
+=========
 
-Various built-in subroutines are called during processing of client-
-and backend requests as well as upon ``vcl.load`` and ``vcl.discard``.
-
-See :ref:`reference-states` for a detailed graphical overview of the
-states and how they relate to core code functions and VCL subroutines.
-
-Built-in subroutines always terminate with a ``return (<action>)``,
-where ``<action>`` determines how processing continues in the request
-processing state machine.
-
-The behaviour of actions is identical or at least similar across
-subroutines, so differences are only documented where relevant.
-
-Common actions are documented in
-:ref:`user-guide-vcl_actions`. Actions specific to only one or some
-subroutines are documented herein.
-
-A default behavior is provided for all :ref:`reference-states` in the
-:ref:`vcl-built-in-code` code.
-
-
-client side
------------
+Client side
+###########
 
 .. _vcl_recv:
 
@@ -48,40 +23,41 @@ be set as a default for the backend processing side.
 The `vcl_recv` subroutine may terminate with calling ``return()`` on one
 of the following keywords:
 
-  ``fail``
-    see :ref:`fail`
-
-  ``synth(status code, reason)``
-    see :ref:`synth`
-
-  ``restart``
-    see :ref:`restart`
-
-  ``pass``
-    see :ref:`pass`
-
-  ``pipe``
-    see :ref:`pipe`
-
-  ``hash``
-    Continue processing the object as a potential candidate for
-    caching. Passes the control over to :ref:`vcl_hash`.
-
-  ``purge``
-    Purge the object and it's variants. Control passes through
-    :ref:`vcl_hash` to :ref:`vcl_purge`.
-
-  ``vcl(label)``
-    Switch to vcl labelled *label*.
-
-    This will roll back the request as if ``std.rollback(req)`` was
-    called and continue vcl processing in :ref:`vcl_recv` of the vcl
-    labelled *label* as if it was the active vcl.
-
-    The ``vcl(label)`` return is only valid while the ``req.restarts``
-    count is zero and if used from the active vcl.
-
-    See the :ref:`ref_cli_vcl_label` command.
+  |
+  | ``fail``
+  |  see :ref:`fail`
+  |
+  | ``synth(status code, reason)``
+  |  see :ref:`synth`
+  |
+  | ``restart``
+  |  see :ref:`restart`
+  |
+  | ``pass``
+  |  see :ref:`pass`
+  |
+  | ``pipe``
+  |  see :ref:`pipe`
+  |
+  | ``hash``
+  |  Continue processing the object as a potential candidate for
+  |  caching. Passes the control over to :ref:`vcl_hash`.
+  |
+  | ``purge``
+  |  Purge the object and it's variants. Control passes through
+  |  :ref:`vcl_hash` to :ref:`vcl_purge`.
+  |
+  | ``vcl(label)``
+  |  Switch to vcl labelled *label*.
+  |
+  |  This will roll back the request as if ``std.rollback(req)`` was
+  |  called and continue vcl processing in :ref:`vcl_recv` of the vcl
+  |  labelled *label* as if it was the active vcl.
+  |
+  |  The ``vcl(label)`` return is only valid while the ``req.restarts``
+  |  count is zero and if used from the active vcl.
+  |
+  |  See the :ref:`ref_cli_vcl_label` command.
 
 .. _vcl_pipe:
 
@@ -98,14 +74,15 @@ other VCL subroutine will ever get called after `vcl_pipe`.
 The `vcl_pipe` subroutine may terminate with calling ``return()`` with one
 of the following keywords:
 
-  ``fail``
-    see   :ref:`fail`
-
-  ``synth(status code, reason)``
-    see  :ref:`synth`
-
-  ``pipe``
-    Proceed with pipe mode.
+  |
+  | ``fail``
+  |  see :ref:`fail`
+  |
+  | ``synth(status code, reason)``
+  |  see :ref:`synth`
+  |
+  | ``pipe``
+  |  Proceed with pipe mode.
 
 .. _vcl_pass:
 
@@ -120,17 +97,18 @@ submitted over the same client connection are handled normally.
 The `vcl_pass` subroutine may terminate with calling ``return()`` with one
 of the following keywords:
 
-  ``fail``
-    see  :ref:`fail`
-
-  ``synth(status code, reason)``
-    see  :ref:`synth`
-
-  ``restart``
-    see  :ref:`restart`
-
-  ``fetch``
-    Proceed with pass mode - initiate a backend request.
+  |
+  | ``fail``
+  |  see :ref:`fail`
+  |
+  | ``synth(status code, reason)``
+  |  see :ref:`synth`
+  |
+  | ``restart``
+  |  see :ref:`restart`
+  |
+  | ``fetch``
+  |  Proceed with pass mode - initiate a backend request.
 
 .. _vcl_hash:
 
@@ -143,26 +121,27 @@ used as a key to look up the object in Varnish.
 The `vcl_hash` subroutine may terminate with calling ``return()`` with one
 of the following keywords:
 
-  ``fail``
-    see  :ref:`fail`
-
-  ``lookup``
-    Look up the object in cache.
-
-    Control passes to :ref:`vcl_purge` when coming from a ``purge``
-    return in `vcl_recv`.
-
-    Otherwise control passes to the next subroutine depending on the
-    result of the cache lookup:
-
-    * a hit: pass to :ref:`vcl_hit`
-
-    * a miss or a hit on a hit-for-miss object (an object with
-      ``obj.uncacheable == true``): pass to :ref:`vcl_miss`
-
-    * a hit on a hit-for-pass object (for which ``pass(DURATION)`` had been
-      previously returned from ``vcl_backend_response``): pass to
-      :ref:`vcl_pass`
+  |
+  | ``fail``
+  |  see :ref:`fail`
+  |
+  | ``lookup``
+  |  Look up the object in cache.
+  |
+  |  Control passes to :ref:`vcl_purge` when coming from a ``purge``
+  |  return in `vcl_recv`.
+  |
+  |  Otherwise control passes to the next subroutine depending on the
+  |  result of the cache lookup:
+  |
+  |  * a hit: pass to :ref:`vcl_hit`
+  |
+  |  * a miss or a hit on a hit-for-miss object (an object with
+  |    ``obj.uncacheable == true``): pass to :ref:`vcl_miss`
+  |
+  |  * a hit on a hit-for-pass object (for which ``pass(DURATION)`` had been
+  |    previously returned from ``vcl_backend_response``): pass to
+  |    :ref:`vcl_pass`
 
 .. _vcl_purge:
 
@@ -174,14 +153,15 @@ Called after the purge has been executed and all its variants have been evicted.
 The `vcl_purge` subroutine may terminate with calling ``return()`` with one
 of the following keywords:
 
-  ``fail``
-    see  :ref:`fail`
-
-  ``synth(status code, reason)``
-    see  :ref:`synth`
-
-  ``restart``
-    see  :ref:`restart`
+  |
+  | ``fail``
+  |  see :ref:`fail`
+  |
+  | ``synth(status code, reason)``
+  |  see :ref:`synth`
+  |
+  | ``restart``
+  |  see :ref:`restart`
 
 .. _vcl_miss:
 
@@ -198,21 +178,22 @@ the backend processing side.
 The `vcl_miss` subroutine may terminate with calling ``return()`` with one
 of the following keywords:
 
-  ``fail``
-    see  :ref:`fail`
-
-  ``synth(status code, reason)``
-    see  :ref:`synth`
-
-  ``restart``
-    see  :ref:`restart`
-
-  ``pass``
-    see  :ref:`pass`
-
-  ``fetch``
-    Retrieve the requested object from the backend. Control will
-    eventually pass to `vcl_backend_fetch`.
+  |
+  | ``fail``
+  |  see :ref:`fail`
+  |
+  | ``synth(status code, reason)``
+  |  see :ref:`synth`
+  |
+  | ``restart``
+  |  see :ref:`restart`
+  |
+  | ``pass``
+  |  see :ref:`pass`
+  |
+  | ``fetch``
+  |  Retrieve the requested object from the backend. Control will
+  |  eventually pass to `vcl_backend_fetch`.
 
 .. _vcl_hit:
 
@@ -226,21 +207,21 @@ stale: It can have a zero or negative `ttl` with only `grace` or
 The `vcl_hit` subroutine may terminate with calling ``return()``
 with one of the following keywords:
 
-  ``fail``
-    see  :ref:`fail`
-
-  ``synth(status code, reason)``
-    see  :ref:`synth`
-
-  ``restart``
-    see  :ref:`restart`
-
-  ``pass``
-    see  :ref:`pass`
-
-  ``deliver``
-    Deliver the object. If it is stale, a background fetch to refresh
-    it is triggered.
+  | ``fail``
+  |  see :ref:`fail`
+  |
+  | ``synth(status code, reason)``
+  |  see :ref:`synth`
+  |
+  | ``restart``
+  |  see :ref:`restart`
+  |
+  | ``pass``
+  |  see :ref:`pass`
+  |
+  | ``deliver``
+  |  Deliver the object. If it is stale, a background fetch to refresh
+  |  it is triggered.
 
 .. _vcl_deliver:
 
@@ -252,17 +233,18 @@ Called before any object except a `vcl_synth` result is delivered to the client.
 The `vcl_deliver` subroutine may terminate with calling ``return()`` with one
 of the following keywords:
 
-  ``fail``
-    see  :ref:`fail`
-
-  ``synth(status code, reason)``
-    see  :ref:`synth`
-
-  ``restart``
-    see  :ref:`restart`
-
-  ``deliver``
-    Deliver the object to the client.
+  |
+  | ``fail``
+  |  see :ref:`fail`
+  |
+  | ``synth(status code, reason)``
+  |  see :ref:`synth`
+  |
+  | ``restart``
+  |  see :ref:`restart`
+  |
+  | ``deliver``
+  |  Deliver the object to the client.
 
 .. _vcl_synth:
 
@@ -279,18 +261,19 @@ A `vcl_synth` defined object never enters the cache, contrary to a
 The subroutine may terminate with calling ``return()`` with one of the
 following keywords:
 
-  ``fail``
-    see  :ref:`fail`
-
-  ``restart``
-    see  :ref:`restart`
-
-  ``deliver``
-    Directly deliver the object defined by `vcl_synth` to the client
-    without calling `vcl_deliver`.
+  |
+  | ``fail``
+  |  see :ref:`fail`
+  |
+  | ``restart``
+  |  see :ref:`restart`
+  |
+  | ``deliver``
+  |  Directly deliver the object defined by `vcl_synth` to the client
+  |  without calling `vcl_deliver`.
 
 Backend Side
-------------
+############
 
 .. _vcl_backend_fetch:
 
@@ -303,19 +286,20 @@ typically alter the request before it gets to the backend.
 The `vcl_backend_fetch` subroutine may terminate with calling
 ``return()`` with one of the following keywords:
 
-  ``fail``
-    see  :ref:`fail`
-
-  ``abandon``
-    see  :ref:`abandon`
-
-  ``fetch``
-    Fetch the object from the backend.
-
-  ``error(status code, reason)``
-    Transition to :ref:`vcl_backend_error` with ``beresp.status`` and
-    ``beresp.reason`` being preset to the arguments of ``error()`` if
-    arguments are provided.
+  |
+  | ``fail``
+  |  see :ref:`fail`
+  |
+  | ``abandon``
+  |  see :ref:`abandon`
+  |
+  | ``fetch``
+  |  Fetch the object from the backend.
+  |
+  | ``error(status code, reason)``
+  |  Transition to :ref:`vcl_backend_error` with ``beresp.status`` and
+  |  ``beresp.reason`` being preset to the arguments of ``error()`` if
+  |  arguments are provided.
 
 Before calling `vcl_backend_fetch`, Varnish core prepares the `bereq`
 backend request as follows:
@@ -356,32 +340,33 @@ the backend.
 The `vcl_backend_response` subroutine may terminate with calling
 ``return()`` with one of the following keywords:
 
-  ``fail``
-    see  :ref:`fail`
-
-  ``abandon``
-    see  :ref:`abandon`
-
-  ``deliver``
-    For a 304 response, create an updated cache object.
-    Otherwise, fetch the object body from the backend and initiate
-    delivery to any waiting client requests, possibly in parallel
-    (streaming).
-
-  ``retry``
-    Retry the backend transaction. Increases the `retries` counter.
-    If the number of retries is higher than *max_retries*,
-    control will be passed to :ref:`vcl_backend_error`.
-
-  ``pass(duration)``
-    Mark the object as a hit-for-pass for the given duration. Subsequent
-    lookups hitting this object will be turned into passed transactions,
-    as if ``vcl_recv`` had returned ``pass``.
-
-  ``error(status code, reason)``
-    Transition to :ref:`vcl_backend_error` with ``beresp.status`` and
-    ``beresp.reason`` being preset to the arguments of ``error()`` if
-    arguments are provided.
+  |
+  | ``fail``
+  |  see :ref:`fail`
+  |
+  | ``abandon``
+  |  see :ref:`abandon`
+  |
+  | ``deliver``
+  |  For a 304 response, create an updated cache object.
+  |  Otherwise, fetch the object body from the backend and initiate
+  |  delivery to any waiting client requests, possibly in parallel
+  |  (streaming).
+  |
+  | ``retry``
+  |  Retry the backend transaction. Increases the `retries` counter.
+  |  If the number of retries is higher than *max_retries*,
+  |  control will be passed to :ref:`vcl_backend_error`.
+  |
+  | ``pass(duration)``
+  |  Mark the object as a hit-for-pass for the given duration. Subsequent
+  |  lookups hitting this object will be turned into passed transactions,
+  |  as if ``vcl_recv`` had returned ``pass``.
+  |
+  | ``error(status code, reason)``
+  |  Transition to :ref:`vcl_backend_error` with ``beresp.status`` and
+  |  ``beresp.reason`` being preset to the arguments of ``error()`` if
+  |  arguments are provided.
 
 .. _vcl_backend_error:
 
@@ -410,25 +395,26 @@ zero in ``vcl_backend_error``.
 The `vcl_backend_error` subroutine may terminate with calling ``return()``
 with one of the following keywords:
 
-  ``fail``
-    see  :ref:`fail`
-
-  ``abandon``
-    see  :ref:`abandon`
-
-  ``deliver``
-    Deliver and possibly cache the object defined in
-    `vcl_backend_error` **as if it was fetched from the backend**, also
-    referred to as a "backend synth".
-
-  ``retry``
-    Retry the backend transaction. Increases the `retries` counter.
-    If the number of retries is higher than *max_retries*,
-    :ref:`vcl_synth` on the client side is called with ``resp.status``
-    preset to 503.
+  |
+  | ``fail``
+  |  see :ref:`fail`
+  |
+  | ``abandon``
+  |  see :ref:`abandon`
+  |
+  | ``deliver``
+  |  Deliver and possibly cache the object defined in
+  |  `vcl_backend_error` **as if it was fetched from the backend**, also
+  |  referred to as a "backend synth".
+  |
+  | ``retry``
+  |  Retry the backend transaction. Increases the `retries` counter.
+  |  If the number of retries is higher than *max_retries*,
+  |  :ref:`vcl_synth` on the client side is called with ``resp.status``
+  |  preset to 503.
 
 During vcl.load / vcl.discard
------------------------------
+#############################
 
 .. _vcl_init:
 
@@ -441,11 +427,12 @@ Typically used to initialize VMODs.
 The `vcl_init` subroutine may terminate with calling ``return()``
 with one of the following keywords:
 
-  ``ok``
-    Normal return, VCL continues loading.
-
-  ``fail``
-    Abort loading of this VCL.
+  |
+  | ``ok``
+  |  Normal return, VCL continues loading.
+  |
+  | ``fail``
+  |  Abort loading of this VCL.
 
 .. _vcl_fini:
 
@@ -458,5 +445,6 @@ Typically used to clean up VMODs.
 The `vcl_fini` subroutine may terminate with calling ``return()``
 with one of the following keywords:
 
-  ``ok``
-    Normal return, VCL will be discarded.
+  |
+  | ``ok``
+  |  Normal return, VCL will be discarded.
diff --git a/doc/sphinx/users-guide/vcl-actions.rst b/doc/sphinx/users-guide/vcl-actions.rst
index 5eb13c799..b51b1bf92 100644
--- a/doc/sphinx/users-guide/vcl-actions.rst
+++ b/doc/sphinx/users-guide/vcl-actions.rst
@@ -14,7 +14,7 @@ processing in varnish continues as shown in :ref:`reference-states`.
 
 Common actions are documented here, while additional actions specific
 to only one or some subroutines are documented in
-:ref:`vcl-built-in-subs` as well as which action can be used from
+:ref:`vcl-steps(7)` as well as which action can be used from
 which built in subroutine.
 
 common actions for the client and backend side
diff --git a/doc/sphinx/users-guide/vcl-built-in-code.rst b/doc/sphinx/users-guide/vcl-built-in-code.rst
index 2bd72ed50..59383e4ef 100644
--- a/doc/sphinx/users-guide/vcl-built-in-code.rst
+++ b/doc/sphinx/users-guide/vcl-built-in-code.rst
@@ -4,7 +4,7 @@ Built-in VCL
 ============
 
 Whenever a VCL program is loaded, the built-in VCL is appended to it. The
-:ref:`vcl-built-in-subs` have a special property, they can appear multiple
+vcl built-in subs (:ref:`vcl_steps`) have a special property, they can appear multiple
 times and the result is concatenation of all built-in subroutines.
 
 For example, let's take the following snippet::
diff --git a/doc/sphinx/users-guide/vcl-syntax.rst b/doc/sphinx/users-guide/vcl-syntax.rst
index 7ef4dd7e7..10748596a 100644
--- a/doc/sphinx/users-guide/vcl-syntax.rst
+++ b/doc/sphinx/users-guide/vcl-syntax.rst
@@ -99,7 +99,7 @@ Built in subroutines
 
 Varnish has quite a few built-in subroutines that are called for each
 transaction as it flows through Varnish. These built-in subroutines are
-all named ``vcl_*`` and are explained in :ref:`vcl-built-in-subs`.
+all named ``vcl_*`` and are explained in :ref:`vcl_steps`.
 
 Processing in built-in subroutines ends with ``return (<action>)``
 (see :ref:`user-guide-vcl_actions`).
@@ -130,7 +130,7 @@ values.
 
 ``return (<action>)`` (see :ref:`user-guide-vcl_actions`) as shown in
 the example above returns all the way from the top level built in
-subroutine (see :ref:`vcl-built-in-subs`) which, possibly through
+subroutine (see :ref:`vcl_steps`) which, possibly through
 multiple steps, lead to the call of the custom subroutine.
 
 ``return`` without an action resumes execution after the ``call``
diff --git a/doc/sphinx/users-guide/vcl.rst b/doc/sphinx/users-guide/vcl.rst
index 831a24071..2647a6491 100644
--- a/doc/sphinx/users-guide/vcl.rst
+++ b/doc/sphinx/users-guide/vcl.rst
@@ -40,7 +40,6 @@ code commented out in the file `builtin.vcl` that ships with Varnish Cache.
    :maxdepth: 1
 
    vcl-syntax
-   vcl-built-in-subs
    vcl-built-in-code
    vcl-variables
    vcl-actions
diff --git a/man/Makefile.am b/man/Makefile.am
index b78dc7cfe..4b89fce68 100644
--- a/man/Makefile.am
+++ b/man/Makefile.am
@@ -7,6 +7,7 @@ dist_man_MANS = \
 	vcl-backend.7 \
 	vcl-probe.7 \
 	vcl-var.7 \
+	vcl-step.7 \
 	vsl.7 \
 	vsl-query.7 \
 	varnishadm.1 \
@@ -60,6 +61,10 @@ vcl-probe.7: $(top_builddir)/doc/sphinx/reference/vcl-probe.rst
 vcl-var.7: $(top_builddir)/doc/sphinx/reference/vcl-var.rst
 	$(BUILD_MAN) $(top_builddir)/doc/sphinx/reference/vcl-var.rst $@
 
+vcl-step.7: $(top_builddir)/doc/sphinx/reference/vcl-step.rst \
+	$(top_builddir)/doc/sphinx/reference/vcl_step.rst
+	$(BUILD_MAN) $(top_builddir)/doc/sphinx/reference/vcl-step.rst $@
+
 vsl.7: $(top_builddir)/doc/sphinx/reference/vsl.rst \
 	$(top_builddir)/doc/sphinx/include/vsl-tags.rst
 	$(BUILD_MAN) $(top_builddir)/doc/sphinx/reference/vsl.rst $@


More information about the varnish-commit mailing list