Specify structure for custom cmake functions
{ 'foo': { 'flags': ['BAR', 'BAZ'],
'kwargs': {'DEPENDS': '*', 'HEADERS': '*', 'SOURCES': '*'}}}
Use this variable to specify how to parse custom cmake functions. See :ref:`additional-cmd`.
# ----------------------------------
# Options affecting listfile parsing
# ----------------------------------
with section("parse"):
# Specify structure for custom cmake functions
additional_commands = { 'foo': { 'flags': ['BAR', 'BAZ'],
'kwargs': {'DEPENDS': '*', 'HEADERS': '*', 'SOURCES': '*'}}}
Override configurations per-command where available
{}
# ----------------------------------
# Options affecting listfile parsing
# ----------------------------------
with section("parse"):
# Override configurations per-command where available
override_spec = {}
Specify variable tags.
[]
Specify a mapping of variable patterns (python regular expression) to a list of tags. Any time a a variable matching this pattern is encountered the tags can be used to affect the parsing/formatting. For example:
vartags = [
(".*_COMMAND", ["cmdline"])
]
Specifies that any variable ending in _COMMAND be tagged as cmdline.
This will affect the formatting by preventing the arguments from being
vertically wrapped.
Note: this particular rule is builtin so you do not need to include this in your configuration. Use the configuration variable to add new rules.
--vartags [VARTAGS [VARTAGS ...]]
Specify variable tags.
# ----------------------------------
# Options affecting listfile parsing
# ----------------------------------
with section("parse"):
# Specify variable tags.
vartags = []
Specify property tags.
[]
Specify a mapping of property patterns (python regular expression) to a list of tags. Any time a a property matching this pattern is encountered the tags can be used to affect the parsing/formatting. For example:
proptags = [
(".*_DIRECTORIES", ["file-list"])
]
Specifies that any property ending in _DIRECTORIES be tagged as
file-list. In the future this may affect formatting by allowing arguments
to be sorted (but currently has no effect).
Note: this particular rule is builtin so you do not need to include this in your configuration. Use the configuration variable to add new rules.
--proptags [PROPTAGS [PROPTAGS ...]]
Specify property tags.
# ----------------------------------
# Options affecting listfile parsing
# ----------------------------------
with section("parse"):
# Specify property tags.
proptags = []
Disable formatting entirely, making cmake-format a no-op
False
--disable [DISABLE] Disable formatting entirely, making cmake-format a no-
op
# -----------------------------
# Options affecting formatting.
# -----------------------------
with section("format"):
# Disable formatting entirely, making cmake-format a no-op
disable = False
How wide to allow formatted cmake files
80
line_width specifies the number of columns that cmake-format should
fit commands into. This is the number of columns at which arguments will be
wrapped.
# line_width = 80 (default)
add_library(libname STATIC sourcefile_one.cc sourcefile_two.cc
sourcefile_three.cc sourcefile_four.cc)
# line_width = 100
add_library(libname STATIC sourcefile_one.cc sourcefile_two.cc sourcefile_three.cc
sourcefile_four.cc)
--line-width LINE_WIDTH
How wide to allow formatted cmake files
# -----------------------------
# Options affecting formatting.
# -----------------------------
with section("format"):
# How wide to allow formatted cmake files
line_width = 80
How many spaces to tab for indent
2
tab_size indicates how many spaces should be used to indent nested
"scopes". For example:
# tab_size = 2 (default)
if(this_condition_is_true)
message("Hello World")
endif()
# tab_size = 4
if(this_condition_is_true)
message("Hello World")
endif()
--tab-size TAB_SIZE How many spaces to tab for indent
# -----------------------------
# Options affecting formatting.
# -----------------------------
with section("format"):
# How many spaces to tab for indent
tab_size = 2
If true, lines are indented using tab characters (utf-8 0x09) instead of <tab_size> space characters (utf-8 0x20). In cases where the layout would require a fractional tab character, the behavior of the fractional indentation is governed by <fractional_tab_policy>
False
--use-tabchars [USE_TABCHARS]
If true, lines are indented using tab characters
(utf-8 0x09) instead of <tab_size> space characters
(utf-8 0x20). In cases where the layout would require
a fractional tab character, the behavior of the
fractional indentation is governed by
<fractional_tab_policy>
# -----------------------------
# Options affecting formatting.
# -----------------------------
with section("format"):
# If true, lines are indented using tab characters (utf-8 0x09) instead of
# <tab_size> space characters (utf-8 0x20). In cases where the layout would
# require a fractional tab character, the behavior of the fractional
# indentation is governed by <fractional_tab_policy>
use_tabchars = False
If <use_tabchars> is True, then the value of this variable indicates how fractional indentions are handled during whitespace replacement. If set to 'use-space', fractional indentation is left as spaces (utf-8 0x20). If set to round-up fractional indentation is replaced with a single tab character (utf-8 0x09) effectively shifting the column to the next tabstop
'use-space'
--fractional-tab-policy {use-space,round-up}
If <use_tabchars> is True, then the value of this
variable indicates how fractional indentions are
handled during whitespace replacement. If set to 'use-
space', fractional indentation is left as spaces
(utf-8 0x20). If set to `round-up` fractional
indentation is replaced with a single tab character
(utf-8 0x09) effectively shifting the column to the
next tabstop
# -----------------------------
# Options affecting formatting.
# -----------------------------
with section("format"):
# If <use_tabchars> is True, then the value of this variable indicates how
# fractional indentions are handled during whitespace replacement. If set to
# 'use-space', fractional indentation is left as spaces (utf-8 0x20). If set
# to `round-up` fractional indentation is replaced with a single tab character
# (utf-8 0x09) effectively shifting the column to the next tabstop
fractional_tab_policy = 'use-space'
If an argument group contains more than this many sub-groups (parg or kwarg groups) then force it to a vertical layout.
2
A "subgroup" in this context is either a positional or keyword argument group
within the current depth of the statement parse tree. If the number of
"subgroups" at this depth is greater than max_subgroups_hwrap then
hwrap-formatting is inadmissable and a vertical layout will be selected.
The default value for this parameter is 2.
Consider the following two examples:
# This statement has two argument groups, so hwrap is admissible
add_custom_target(target1 ALL COMMAND echo "hello world")
# This statement has three argument groups, so the statement will format
# vertically
add_custom_target(
target2 ALL
COMMAND echo "hello world"
COMMAND echo "hello again")In the first statement, there are two argument groups. We can see them with
--dump parse
└─ BODY: 1:0
└─ STATEMENT: 1:0
├─ FUNNAME: 1:0
├─ LPAREN: 1:17
├─ ARGGROUP: 1:18
│ ├─ PARGGROUP: 1:18 <-- group 1
│ │ ├─ ARGUMENT: 1:18
│ │ └─ FLAG: 1:26
│ └─ KWARGGROUP: 1:30 <-- group 2
│ ├─ KEYWORD: 1:30
│ └─ ARGGROUP: 1:38
│ └─ PARGGROUP: 1:38
│ ├─ ARGUMENT: 1:38
│ └─ ARGUMENT: 1:43
└─ RPAREN: 1:56
The second statement has three argument groups:
└─ BODY: 1:0
└─ STATEMENT: 1:0
├─ FUNNAME: 1:0
├─ LPAREN: 1:17
├─ ARGGROUP: 2:5
│ ├─ PARGGROUP: 2:5 <-- group 1
│ │ ├─ ARGUMENT: 2:5
│ │ └─ FLAG: 2:13
│ ├─ KWARGGROUP: 3:5 <-- group 2
│ │ ├─ KEYWORD: 3:5
│ │ └─ ARGGROUP: 3:13
│ │ └─ PARGGROUP: 3:13
│ │ ├─ ARGUMENT: 3:13
│ │ ├─ ARGUMENT: 3:18
│ └─ KWARGGROUP: 4:5 <-- group 3
│ ├─ KEYWORD: 4:5
│ └─ ARGGROUP: 4:13
│ └─ PARGGROUP: 4:13
│ ├─ ARGUMENT: 4:13
│ └─ ARGUMENT: 4:18
└─ RPAREN: 4:31
--max-subgroups-hwrap MAX_SUBGROUPS_HWRAP
If an argument group contains more than this many sub-
groups (parg or kwarg groups) then force it to a
vertical layout.
# -----------------------------
# Options affecting formatting.
# -----------------------------
with section("format"):
# If an argument group contains more than this many sub-groups (parg or kwarg
# groups) then force it to a vertical layout.
max_subgroups_hwrap = 2
If a positional argument group contains more than this many arguments, then force it to a vertical layout.
6
This configuration parameter is relavent only to positional argument groups. A positional argument group is a list of "plain" arguments. If the number of arguments in the group is greater than this number, then then hwrap-formatting is inadmissable and a vertical layout will be selected.
The default value for this parameter is 6
Consider the following two examples:
# This statement has six arguments in the second group and so hwrap is
# admissible
set(sources filename_one.cc filename_two.cc filename_three.cc
filename_four.cc filename_five.cc filename_six.cc)
# This statement has seven arguments in the second group and so hwrap is
# inadmissible
set(sources
filename_one.cc
filename_two.cc
filename_three.cc
filename_four.cc
filename_five.cc
filename_six.cc
filename_seven.cc)
--max-pargs-hwrap MAX_PARGS_HWRAP
If a positional argument group contains more than this
many arguments, then force it to a vertical layout.
# -----------------------------
# Options affecting formatting.
# -----------------------------
with section("format"):
# If a positional argument group contains more than this many arguments, then
# force it to a vertical layout.
max_pargs_hwrap = 6
If a cmdline positional group consumes more than this many lines without nesting, then invalidate the layout (and nest)
2
max_pargs_hwrap does not apply to positional argument groups for shell
commands. These are never columnized and always hwrapped. However, if the
wrapped format exceeds this many lines, then the group will also be nested.
--max-rows-cmdline MAX_ROWS_CMDLINE
If a cmdline positional group consumes more than this
many lines without nesting, then invalidate the layout
(and nest)
# -----------------------------
# Options affecting formatting.
# -----------------------------
with section("format"):
# If a cmdline positional group consumes more than this many lines without
# nesting, then invalidate the layout (and nest)
max_rows_cmdline = 2
If true, separate flow control names from their parentheses with a space
False
--separate-ctrl-name-with-space [SEPARATE_CTRL_NAME_WITH_SPACE]
If true, separate flow control names from their
parentheses with a space
# -----------------------------
# Options affecting formatting.
# -----------------------------
with section("format"):
# If true, separate flow control names from their parentheses with a space
separate_ctrl_name_with_space = False
If true, separate function names from parentheses with a space
False
--separate-fn-name-with-space [SEPARATE_FN_NAME_WITH_SPACE]
If true, separate function names from parentheses with
a space
# -----------------------------
# Options affecting formatting.
# -----------------------------
with section("format"):
# If true, separate function names from parentheses with a space
separate_fn_name_with_space = False
If a statement is wrapped to more than one line, than dangle the closing parenthesis on its own line.
False
If a statement is wrapped to more than one line, than dangle the closing parenthesis on its own line. For example:
# dangle_parens = False (default)
set(sources filename_one.cc filename_two.cc filename_three.cc
filename_four.cc filename_five.cc filename_six.cc)
# dangle_parens = True
set(sources filename_one.cc filename_two.cc filename_three.cc
filename_four.cc filename_five.cc filename_six.cc
) # <-- this is a dangling parenthesis
The default is false.
--dangle-parens [DANGLE_PARENS]
If a statement is wrapped to more than one line, than
dangle the closing parenthesis on its own line.
# -----------------------------
# Options affecting formatting.
# -----------------------------
with section("format"):
# If a statement is wrapped to more than one line, than dangle the closing
# parenthesis on its own line.
dangle_parens = False
If the trailing parenthesis must be 'dangled' on its on line, then align it to this reference: prefix: the start of the statement, prefix-indent: the start of the statement, plus one indentation level, child: align to the column of the arguments
'prefix'
If the trailing parenthesis must be 'dangled' on it's on line, then align it to this reference. Options are:
prefix: the start of the statement,prefix-indent: the start of the statement, plus one indentation levelchild: align to the column of the arguments
For example:
# dangle_align = "prefix"
set(sources filename_one.cc filename_two.cc filename_three.cc
filename_four.cc filename_five.cc filename_six.cc
) # <-- aligned to the statement
# dangle_align = "prefix-indent"
set(sources filename_one.cc filename_two.cc filename_three.cc
filename_four.cc filename_five.cc filename_six.cc
) # <-- plus one indentation level
# dangle_align = "child"
set(sources filename_one.cc filename_two.cc filename_three.cc
filename_four.cc filename_five.cc filename_six.cc
) # <-- aligned to "sources"
--dangle-align {prefix,prefix-indent,child,off}
If the trailing parenthesis must be 'dangled' on its
on line, then align it to this reference: `prefix`:
the start of the statement, `prefix-indent`: the start
of the statement, plus one indentation level, `child`:
align to the column of the arguments
# -----------------------------
# Options affecting formatting.
# -----------------------------
with section("format"):
# If the trailing parenthesis must be 'dangled' on its on line, then align it
# to this reference: `prefix`: the start of the statement, `prefix-indent`:
# the start of the statement, plus one indentation level, `child`: align to
# the column of the arguments
dangle_align = 'prefix'
If the statement spelling length (including space and parenthesis) is smaller than this amount, then force reject nested layouts.
4
This value only comes into play when considering whether or not to nest
arguments below their parent. If the number of characters in the parent is
less than this value, we will not nest. In the example below, we'll set
line_width=40 for illustration:
# min_prefix_chars = 4 (default)
message(
"With the default value, this "
"string is allowed to nest beneath "
"the statement")
# min_prefix_chars = 8
message("With the default value, this "
"string is allowed to nest beneath "
"the statement")
--min-prefix-chars MIN_PREFIX_CHARS
If the statement spelling length (including space and
parenthesis) is smaller than this amount, then force
reject nested layouts.
# -----------------------------
# Options affecting formatting.
# -----------------------------
with section("format"):
# If the statement spelling length (including space and parenthesis) is
# smaller than this amount, then force reject nested layouts.
min_prefix_chars = 4
If the statement spelling length (including space and parenthesis) is larger than the tab width by more than this amount, then force reject un-nested layouts.
10
--max-prefix-chars MAX_PREFIX_CHARS
If the statement spelling length (including space and
parenthesis) is larger than the tab width by more than
this amount, then force reject un-nested layouts.
# -----------------------------
# Options affecting formatting.
# -----------------------------
with section("format"):
# If the statement spelling length (including space and parenthesis) is larger
# than the tab width by more than this amount, then force reject un-nested
# layouts.
max_prefix_chars = 10
If a candidate layout is wrapped horizontally but it exceeds this many lines, then reject the layout.
2
Usually the layout algorithm will prefer to do a simple "word-wrap" of
positional arguments, if it can. However if such a simple word-wrap would
exceed this many lines, then that layout is rejected, and further passes are
tried. The default value is max_lines_hwrap=2 so, for example:
message("This message can easily be wrapped" "to two lines so there is no"
"problem with using" "horizontal wrapping")
message(
"However this message cannot be wrapped to two lines because the "
"arguments are too long. It would require at least three lines."
"As a result, a simple word-wrap is rejected"
"And each argument"
"gets its own line")
--max-lines-hwrap MAX_LINES_HWRAP
If a candidate layout is wrapped horizontally but it
exceeds this many lines, then reject the layout.
# -----------------------------
# Options affecting formatting.
# -----------------------------
with section("format"):
# If a candidate layout is wrapped horizontally but it exceeds this many
# lines, then reject the layout.
max_lines_hwrap = 2
What style line endings to use in the output.
'unix'
This is a string indicating which style of line ending cmake-format should
use when writing out the formatted file. If line_ending="unix" (default)
then the output will contain a single newline character (\n) at the end of
each line. If line_ending="windows" then the output will contain a
carriage-return and newline pair (\r\n). If line_ending="auto" then
cmake-format will observe the first line-ending of the input file and will
use style that all lines in the output.
--line-ending {windows,unix,auto}
What style line endings to use in the output.
# -----------------------------
# Options affecting formatting.
# -----------------------------
with section("format"):
# What style line endings to use in the output.
line_ending = 'unix'
Format command names consistently as 'lower' or 'upper' case
'canonical'
cmake ignores case in command names. Very old projects tend to use
uppercase for command names, while modern projects tend to use lowercase.
There are three options for this variable:
upper: format commands as uppercaselower: format commands as lowercasecanonical: format standard commands as they are formatted in thecmakedocumentation.
canonical is generally the same as lower except that some third-party
find modules that have moved into the distribution (e.g.
ExternalProject_Add).
--command-case {lower,upper,canonical,unchanged}
Format command names consistently as 'lower' or
'upper' case
# -----------------------------
# Options affecting formatting.
# -----------------------------
with section("format"):
# Format command names consistently as 'lower' or 'upper' case
command_case = 'canonical'
Format keywords consistently as 'lower' or 'upper' case
'unchanged'
cmake ignores the case of sentinal words (keywords) in argument lists.
Generally projects tend to prefer uppercase (keyword_case="upper") which is
the default. Alternatively, this may also be set to lower to format
keywords as lowercase.
--keyword-case {lower,upper,unchanged}
Format keywords consistently as 'lower' or 'upper'
case
# -----------------------------
# Options affecting formatting.
# -----------------------------
with section("format"):
# Format keywords consistently as 'lower' or 'upper' case
keyword_case = 'unchanged'
A list of command names which should always be wrapped
[]
--always-wrap [ALWAYS_WRAP [ALWAYS_WRAP ...]]
A list of command names which should always be wrapped
# -----------------------------
# Options affecting formatting.
# -----------------------------
with section("format"):
# A list of command names which should always be wrapped
always_wrap = []
If true, the argument lists which are known to be sortable will be sorted lexicographicall
True
--enable-sort [ENABLE_SORT]
If true, the argument lists which are known to be
sortable will be sorted lexicographicall
# -----------------------------
# Options affecting formatting.
# -----------------------------
with section("format"):
# If true, the argument lists which are known to be sortable will be sorted
# lexicographicall
enable_sort = True
If true, the parsers may infer whether or not an argument list is sortable (without annotation).
False
--autosort [AUTOSORT]
If true, the parsers may infer whether or not an
argument list is sortable (without annotation).
# -----------------------------
# Options affecting formatting.
# -----------------------------
with section("format"):
# If true, the parsers may infer whether or not an argument list is sortable
# (without annotation).
autosort = False
By default, if cmake-format cannot successfully fit everything into the desired linewidth it will apply the last, most agressive attempt that it made. If this flag is True, however, cmake-format will print error, exit with non-zero status code, and write-out nothing
False
By default, if cmake-format cannot successfully fit everything into the desired linewidth it will apply the last, most agressive attempt that it made. If this flag is True, however, cmake-format will print error, exit with non- zero status code, and write-out nothing
--require-valid-layout [REQUIRE_VALID_LAYOUT]
By default, if cmake-format cannot successfully fit
everything into the desired linewidth it will apply
the last, most agressive attempt that it made. If this
flag is True, however, cmake-format will print error,
exit with non-zero status code, and write-out nothing
# -----------------------------
# Options affecting formatting.
# -----------------------------
with section("format"):
# By default, if cmake-format cannot successfully fit everything into the
# desired linewidth it will apply the last, most agressive attempt that it
# made. If this flag is True, however, cmake-format will print error, exit
# with non-zero status code, and write-out nothing
require_valid_layout = False
A dictionary mapping layout nodes to a list of wrap decisions. See the documentation for more information.
{}
See the :ref:`Formatting Algorithm <formatting-algorithm>` section for more information on how cmake-format uses multiple passes to converge on the final layout of the listfile source code. This option can be used to override the default behavior. The format of this option is a dictionary, where the keys are the names of the different layout node classes:
- StatementNode
- ArgGroupNode
- KWargGroupNode
- PargGroupNode
- ParenGroupNode
The dictionary values are a list of pairs (2-tuples) in the form of
(passno, wrap-decision). Where passno is the pass number at
which the wrap-decision becomes active, and wrap-decision is a boolean
(true/false). For each layout pass, the decision of whether or not the
node should wrap (either nested, or vertical) is looked-up from this map.
# -----------------------------
# Options affecting formatting.
# -----------------------------
with section("format"):
# A dictionary mapping layout nodes to a list of wrap decisions. See the
# documentation for more information.
layout_passes = {}
What character to use for bulleted lists
'*'
--bullet-char BULLET_CHAR
What character to use for bulleted lists
# ------------------------------------------------
# Options affecting comment reflow and formatting.
# ------------------------------------------------
with section("markup"):
# What character to use for bulleted lists
bullet_char = '*'
What character to use as punctuation after numerals in an enumerated list
'.'
--enum-char ENUM_CHAR
What character to use as punctuation after numerals in
an enumerated list
# ------------------------------------------------
# Options affecting comment reflow and formatting.
# ------------------------------------------------
with section("markup"):
# What character to use as punctuation after numerals in an enumerated list
enum_char = '.'
If comment markup is enabled, don't reflow the first comment block in each listfile. Use this to preserve formatting of your copyright/license statements.
False
--first-comment-is-literal [FIRST_COMMENT_IS_LITERAL]
If comment markup is enabled, don't reflow the first
comment block in each listfile. Use this to preserve
formatting of your copyright/license statements.
# ------------------------------------------------
# Options affecting comment reflow and formatting.
# ------------------------------------------------
with section("markup"):
# If comment markup is enabled, don't reflow the first comment block in each
# listfile. Use this to preserve formatting of your copyright/license
# statements.
first_comment_is_literal = False
If comment markup is enabled, don't reflow any comment block which matches this (regex) pattern. Default is None (disabled).
None
--literal-comment-pattern LITERAL_COMMENT_PATTERN
If comment markup is enabled, don't reflow any comment
block which matches this (regex) pattern. Default is
`None` (disabled).
# ------------------------------------------------
# Options affecting comment reflow and formatting.
# ------------------------------------------------
with section("markup"):
# If comment markup is enabled, don't reflow any comment block which matches
# this (regex) pattern. Default is `None` (disabled).
literal_comment_pattern = None
Regular expression to match preformat fences in comments default= r'^\s*([`~]{3}[`~]*)(.*)$'
'^\\s*([`~]{3}[`~]*)(.*)$'
--fence-pattern FENCE_PATTERN
Regular expression to match preformat fences in
comments default= ``r'^\s*([`~]{3}[`~]*)(.*)$'``
# ------------------------------------------------
# Options affecting comment reflow and formatting.
# ------------------------------------------------
with section("markup"):
# Regular expression to match preformat fences in comments default=
# ``r'^\s*([`~]{3}[`~]*)(.*)$'``
fence_pattern = '^\\s*([`~]{3}[`~]*)(.*)$'
Regular expression to match rulers in comments default= r'^\s*[^\w\s]{3}.*[^\w\s]{3}$'
'^\\s*[^\\w\\s]{3}.*[^\\w\\s]{3}$'
--ruler-pattern RULER_PATTERN
Regular expression to match rulers in comments
default= ``r'^\s*[^\w\s]{3}.*[^\w\s]{3}$'``
# ------------------------------------------------
# Options affecting comment reflow and formatting.
# ------------------------------------------------
with section("markup"):
# Regular expression to match rulers in comments default=
# ``r'^\s*[^\w\s]{3}.*[^\w\s]{3}$'``
ruler_pattern = '^\\s*[^\\w\\s]{3}.*[^\\w\\s]{3}$'
If a comment line matches starts with this pattern then it is explicitly a trailing comment for the preceeding argument. Default is '#<'
'#<'
--explicit-trailing-pattern EXPLICIT_TRAILING_PATTERN
If a comment line matches starts with this pattern
then it is explicitly a trailing comment for the
preceeding argument. Default is '#<'
# ------------------------------------------------
# Options affecting comment reflow and formatting.
# ------------------------------------------------
with section("markup"):
# If a comment line matches starts with this pattern then it is explicitly a
# trailing comment for the preceeding argument. Default is '#<'
explicit_trailing_pattern = '#<'
If a comment line starts with at least this many consecutive hash characters, then don't lstrip() them off. This allows for lazy hash rulers where the first hash char is not separated by space
10
--hashruler-min-length HASHRULER_MIN_LENGTH
If a comment line starts with at least this many
consecutive hash characters, then don't lstrip() them
off. This allows for lazy hash rulers where the first
hash char is not separated by space
# ------------------------------------------------
# Options affecting comment reflow and formatting.
# ------------------------------------------------
with section("markup"):
# If a comment line starts with at least this many consecutive hash
# characters, then don't lstrip() them off. This allows for lazy hash rulers
# where the first hash char is not separated by space
hashruler_min_length = 10
If true, then insert a space between the first hash char and remaining hash chars in a hash ruler, and normalize its length to fill the column
True
--canonicalize-hashrulers [CANONICALIZE_HASHRULERS]
If true, then insert a space between the first hash
char and remaining hash chars in a hash ruler, and
normalize its length to fill the column
# ------------------------------------------------
# Options affecting comment reflow and formatting.
# ------------------------------------------------
with section("markup"):
# If true, then insert a space between the first hash char and remaining hash
# chars in a hash ruler, and normalize its length to fill the column
canonicalize_hashrulers = True
enable comment markup parsing and reflow
True
--enable-markup [ENABLE_MARKUP]
enable comment markup parsing and reflow
# ------------------------------------------------
# Options affecting comment reflow and formatting.
# ------------------------------------------------
with section("markup"):
# enable comment markup parsing and reflow
enable_markup = True
a list of lint codes to disable
[]
--disabled-codes [DISABLED_CODES [DISABLED_CODES ...]]
a list of lint codes to disable
# ----------------------------
# Options affecting the linter
# ----------------------------
with section("lint"):
# a list of lint codes to disable
disabled_codes = []
regular expression pattern describing valid function names
'[0-9a-z_]+'
--function-pattern FUNCTION_PATTERN
regular expression pattern describing valid function
names
# ----------------------------
# Options affecting the linter
# ----------------------------
with section("lint"):
# regular expression pattern describing valid function names
function_pattern = '[0-9a-z_]+'
regular expression pattern describing valid macro names
'[0-9A-Z_]+'
--macro-pattern MACRO_PATTERN
regular expression pattern describing valid macro
names
# ----------------------------
# Options affecting the linter
# ----------------------------
with section("lint"):
# regular expression pattern describing valid macro names
macro_pattern = '[0-9A-Z_]+'
regular expression pattern describing valid names for variables with global (cache) scope
'[A-Z][0-9A-Z_]+'
--global-var-pattern GLOBAL_VAR_PATTERN
regular expression pattern describing valid names for
variables with global (cache) scope
# ----------------------------
# Options affecting the linter
# ----------------------------
with section("lint"):
# regular expression pattern describing valid names for variables with global
# (cache) scope
global_var_pattern = '[A-Z][0-9A-Z_]+'
regular expression pattern describing valid names for variables with global scope (but internal semantic)
'_[A-Z][0-9A-Z_]+'
--internal-var-pattern INTERNAL_VAR_PATTERN
regular expression pattern describing valid names for
variables with global scope (but internal semantic)
# ----------------------------
# Options affecting the linter
# ----------------------------
with section("lint"):
# regular expression pattern describing valid names for variables with global
# scope (but internal semantic)
internal_var_pattern = '_[A-Z][0-9A-Z_]+'
regular expression pattern describing valid names for variables with local scope
'[a-z][a-z0-9_]+'
--local-var-pattern LOCAL_VAR_PATTERN
regular expression pattern describing valid names for
variables with local scope
# ----------------------------
# Options affecting the linter
# ----------------------------
with section("lint"):
# regular expression pattern describing valid names for variables with local
# scope
local_var_pattern = '[a-z][a-z0-9_]+'
regular expression pattern describing valid names for privatedirectory variables
'_[0-9a-z_]+'
--private-var-pattern PRIVATE_VAR_PATTERN
regular expression pattern describing valid names for
privatedirectory variables
# ----------------------------
# Options affecting the linter
# ----------------------------
with section("lint"):
# regular expression pattern describing valid names for privatedirectory
# variables
private_var_pattern = '_[0-9a-z_]+'
regular expression pattern describing valid names for public directory variables
'[A-Z][0-9A-Z_]+'
--public-var-pattern PUBLIC_VAR_PATTERN
regular expression pattern describing valid names for
public directory variables
# ----------------------------
# Options affecting the linter
# ----------------------------
with section("lint"):
# regular expression pattern describing valid names for public directory
# variables
public_var_pattern = '[A-Z][0-9A-Z_]+'
regular expression pattern describing valid names for function/macro arguments and loop variables.
'[a-z][a-z0-9_]+'
--argument-var-pattern ARGUMENT_VAR_PATTERN
regular expression pattern describing valid names for
function/macro arguments and loop variables.
# ----------------------------
# Options affecting the linter
# ----------------------------
with section("lint"):
# regular expression pattern describing valid names for function/macro
# arguments and loop variables.
argument_var_pattern = '[a-z][a-z0-9_]+'
regular expression pattern describing valid names for keywords used in functions or macros
'[A-Z][0-9A-Z_]+'
--keyword-pattern KEYWORD_PATTERN
regular expression pattern describing valid names for
keywords used in functions or macros
# ----------------------------
# Options affecting the linter
# ----------------------------
with section("lint"):
# regular expression pattern describing valid names for keywords used in
# functions or macros
keyword_pattern = '[A-Z][0-9A-Z_]+'
In the heuristic for C0201, how many conditionals to match within a loop in before considering the loop a parser.
2
--max-conditionals-custom-parser MAX_CONDITIONALS_CUSTOM_PARSER
In the heuristic for C0201, how many conditionals to
match within a loop in before considering the loop a
parser.
# ----------------------------
# Options affecting the linter
# ----------------------------
with section("lint"):
# In the heuristic for C0201, how many conditionals to match within a loop in
# before considering the loop a parser.
max_conditionals_custom_parser = 2
Require at least this many newlines between statements
1
--min-statement-spacing MIN_STATEMENT_SPACING
Require at least this many newlines between statements
# ----------------------------
# Options affecting the linter
# ----------------------------
with section("lint"):
# Require at least this many newlines between statements
min_statement_spacing = 1
Require no more than this many newlines between statements
2
--max-statement-spacing MAX_STATEMENT_SPACING
Require no more than this many newlines between
statements
# ----------------------------
# Options affecting the linter
# ----------------------------
with section("lint"):
# Require no more than this many newlines between statements
max_statement_spacing = 2
6
--max-returns MAX_RETURNS
# ----------------------------
# Options affecting the linter
# ----------------------------
with section("lint"):
max_returns = 6
12
--max-branches MAX_BRANCHES
# ----------------------------
# Options affecting the linter
# ----------------------------
with section("lint"):
max_branches = 12
5
--max-arguments MAX_ARGUMENTS
# ----------------------------
# Options affecting the linter
# ----------------------------
with section("lint"):
max_arguments = 5
15
--max-localvars MAX_LOCALVARS
# ----------------------------
# Options affecting the linter
# ----------------------------
with section("lint"):
max_localvars = 15
50
--max-statements MAX_STATEMENTS
# ----------------------------
# Options affecting the linter
# ----------------------------
with section("lint"):
max_statements = 50
If true, emit the unicode byte-order mark (BOM) at the start of the file
False
If true (the default is false) then output the unicode byte-order at
the start of the document.
--emit-byteorder-mark [EMIT_BYTEORDER_MARK]
If true, emit the unicode byte-order mark (BOM) at the
start of the file
# -------------------------------
# Options affecting file encoding
# -------------------------------
with section("encode"):
# If true, emit the unicode byte-order mark (BOM) at the start of the file
emit_byteorder_mark = False
Specify the encoding of the input file. Defaults to utf-8
'utf-8'
Specify the input encoding of the file. The format of this string is anything
understood by the encoding= keyword of the python open() function.
The default is utf-8.
--input-encoding INPUT_ENCODING
Specify the encoding of the input file. Defaults to
utf-8
# -------------------------------
# Options affecting file encoding
# -------------------------------
with section("encode"):
# Specify the encoding of the input file. Defaults to utf-8
input_encoding = 'utf-8'
Specify the encoding of the output file. Defaults to utf-8. Note that cmake only claims to support utf-8 so be careful when using anything else
'utf-8'
Specify the output encoding of the file. The format of this string is anything
understood by the encoding= keyword of the python open() function.
The default is utf-8.
--output-encoding OUTPUT_ENCODING
Specify the encoding of the output file. Defaults to
utf-8. Note that cmake only claims to support utf-8 so
be careful when using anything else
# -------------------------------
# Options affecting file encoding
# -------------------------------
with section("encode"):
# Specify the encoding of the output file. Defaults to utf-8. Note that cmake
# only claims to support utf-8 so be careful when using anything else
output_encoding = 'utf-8'
A dictionary containing any per-command configuration overrides. Currently only command_case is supported.
{}
# -------------------------------------
# Miscellaneous configurations options.
# -------------------------------------
with section("misc"):
# A dictionary containing any per-command configuration overrides. Currently
# only `command_case` is supported.
per_command = {}