neulab/tldr huggingface dataset:
CTest Update Step In a CTest Script, the ctest_update() command runs this step.  Arguments to the command may specify some of the step settings.
Configuration settings to specify the version control tool include:
BZRCommand bzr command-line tool to use if source tree is managed by Bazaar.
• CTest Script variable: CTEST_BZR_COMMAND
• CTest module variable: none
BZRUpdateOptions Command-line options to the BZRCommand when updating the source.
• CTest Script variable: CTEST_BZR_UPDATE_OPTIONS
CVSCommand cvs command-line tool to use if source tree is managed by CVS.
• CTest Script variable: CTEST_CVS_COMMAND
• CTest module variable: CVSCOMMAND
CVSUpdateOptions Command-line options to the CVSCommand when updating the source.
• CTest Script variable: CTEST_CVS_UPDATE_OPTIONS
• CTest module variable: CVS_UPDATE_OPTIONS
GITCommand git command-line tool to use if source tree is managed by Git.
• CTest Script variable: CTEST_GIT_COMMAND
• CTest module variable: GITCOMMAND
The source tree is updated by git fetch followed by git reset --hard to the FETCH_HEAD.  The result is the same as git pull except that any local modifications are overwritten.  Use GITUpdateCustom to specify a different approach.
GITInitSubmodules If set, CTest will update the repository's submodules before updating.
• CTest Script variable: CTEST_GIT_INIT_SUBMODULES
• CTest module variable: CTEST_GIT_INIT_SUBMODULES
GITUpdateCustom Specify a custom command line (as a semicolon-separated list) to run in the source tree (Git work tree) to update it instead of running the GITCommand.
• CTest Script variable: CTEST_GIT_UPDATE_CUSTOM
• CTest module variable: CTEST_GIT_UPDATE_CUSTOM
GITUpdateOptions Command-line options to the GITCommand when updating the source.
• CTest Script variable: CTEST_GIT_UPDATE_OPTIONS
• CTest module variable: GIT_UPDATE_OPTIONS
HGCommand hg command-line tool to use if source tree is managed by Mercurial.
• CTest Script variable: CTEST_HG_COMMAND
HGUpdateOptions Command-line options to the HGCommand when updating the source.
• CTest Script variable: CTEST_HG_UPDATE_OPTIONS
P4Client Value of the -c option to the P4Command.
• CTest Script variable: CTEST_P4_CLIENT
• CTest module variable: CTEST_P4_CLIENT
P4Command p4 command-line tool to use if source tree is managed by Perforce.
• CTest Script variable: CTEST_P4_COMMAND
• CTest module variable: P4COMMAND
P4Options Command-line options to the P4Command for all invocations.
• CTest Script variable: CTEST_P4_OPTIONS
• CTest module variable: CTEST_P4_OPTIONS
P4UpdateCustom Specify a custom command line (as a semicolon-separated list) to run in the source tree (Perforce tree) to update it instead of running the P4Command.
• CTest Script variable: none
• CTest module variable: CTEST_P4_UPDATE_CUSTOM
P4UpdateOptions Command-line options to the P4Command when updating the source.
• CTest Script variable: CTEST_P4_UPDATE_OPTIONS
• CTest module variable: CTEST_P4_UPDATE_OPTIONS
SVNCommand svn command-line tool to use if source tree is managed by Subversion.
• CTest Script variable: CTEST_SVN_COMMAND
• CTest module variable: SVNCOMMAND
SVNOptions Command-line options to the SVNCommand for all invocations.
• CTest Script variable: CTEST_SVN_OPTIONS
• CTest module variable: CTEST_SVN_OPTIONS
SVNUpdateOptions Command-line options to the SVNCommand when updating the source.
• CTest Script variable: CTEST_SVN_UPDATE_OPTIONS
• CTest module variable: SVN_UPDATE_OPTIONS
UpdateCommand Specify the version-control command-line tool to use without detecting the VCS that manages the source tree.
• CTest Script variable: CTEST_UPDATE_COMMAND
• CTest module variable: <VCS>COMMAND when UPDATE_TYPE is <vcs>, else UPDATE_COMMAND
UpdateOptions Command-line options to the UpdateCommand.
• CTest Script variable: CTEST_UPDATE_OPTIONS
• CTest module variable: <VCS>_UPDATE_OPTIONS when UPDATE_TYPE is <vcs>, else UPDATE_OPTIONS
UpdateType Specify the version-control system that manages the source tree if it cannot be detected automatically.  The value may be bzr, cvs, git, hg, p4, or svn.
• CTest Script variable: none, detected from source tree
• CTest module variable: UPDATE_TYPE if set, else CTEST_UPDATE_TYPE
UpdateVersionOnly Specify that you want the version control update command to only discover the current version that is checked out, and not to update to a different version.
• CTest Script variable: CTEST_UPDATE_VERSION_ONLY
UpdateVersionOverride Specify the current version of your source tree.
When this variable is set to a non-empty string, CTest will report the value you specified rather than using the update command to discover the current version that is checked out. Use of this variable supersedes UpdateVersionOnly. Like UpdateVersionOnly, using this variable tells CTest not to update the source tree to a different version.
• CTest Script variable: CTEST_UPDATE_VERSION_OVERRIDE
Additional configuration settings include:
NightlyStartTime In the Nightly dashboard mode, specify the "nightly start time". With centralized version control systems (cvs and svn), the Update step checks out the version of the software as of this time so that multiple clients choose a common version to test.  This is not well-defined in distributed version-control systems so the setting is ignored.
• CTest Script variable: CTEST_NIGHTLY_START_TIME
• CTest module variable: NIGHTLY_START_TIME if set, else CTEST_NIGHTLY_START_TIME
CTest Configure Step In a CTest Script, the ctest_configure() command runs this step. Arguments to the command may specify some of the step settings.
ConfigureCommand Command-line to launch the software configuration process.  It will be executed in the location specified by the BuildDirectory setting.
• CTest Script variable: CTEST_CONFIGURE_COMMAND
• CTest module variable: CMAKE_COMMAND followed by PROJECT_SOURCE_DIR
LabelsForSubprojects Specify a semicolon-separated list of labels that will be treated as subprojects. This mapping will be passed on to CDash when configure, test or build results are submitted.
• CTest Script variable: CTEST_LABELS_FOR_SUBPROJECTS
• CTest module variable: CTEST_LABELS_FOR_SUBPROJECTS
CTest Build Step In a CTest Script, the ctest_build() command runs this step.  Arguments to the command may specify some of the step settings.
DefaultCTestConfigurationType When the build system to be launched allows build-time selection of the configuration (e.g. Debug, Release), this specifies the default configuration to be built when no -C option is given to the ctest command.  The value will be substituted into the value of MakeCommand to replace the literal string ${CTEST_CONFIGURATION_TYPE} if it appears.
• CTest Script variable: CTEST_CONFIGURATION_TYPE
• CTest module variable: DEFAULT_CTEST_CONFIGURATION_TYPE, initialized by the CMAKE_CONFIG_TYPE environment variable
MakeCommand Command-line to launch the software build process.  It will be executed in the location specified by the BuildDirectory setting.
• CTest Script variable: CTEST_BUILD_COMMAND
• CTest module variable: MAKECOMMAND, initialized by the build_command() command
UseLaunchers For build trees generated by CMake using one of the Makefile Generators or the Ninja generator, specify whether the CTEST_USE_LAUNCHERS feature is enabled by the CTestUseLaunchers module (also included by the CTest module).  When enabled, the generated build system wraps each invocation of the compiler, linker, or custom command line with a "launcher" that communicates with CTest via environment variables and files to report granular build warning and error information.  Otherwise, CTest must "scrape" the build output log for diagnostics.
• CTest Script variable: CTEST_USE_LAUNCHERS
• CTest module variable: CTEST_USE_LAUNCHERS
CTest Test Step In a CTest Script, the ctest_test() command runs this step.  Arguments to the command may specify some of the step settings.
ResourceSpecFile Specify a resource specification file.
• CTest Script variable: CTEST_RESOURCE_SPEC_FILE
• CTest module variable: CTEST_RESOURCE_SPEC_FILE
See Resource Allocation for more information.
TestLoad While running tests in parallel (e.g. with -j), try not to start tests when they may cause the CPU load to pass above a given threshold.
• CTest Script variable: CTEST_TEST_LOAD
• CTest module variable: CTEST_TEST_LOAD
TimeOut The default timeout for each test if not specified by the TIMEOUT test property.
• CTest Script variable: CTEST_TEST_TIMEOUT
• CTest module variable: DART_TESTING_TIMEOUT
To report extra test values to CDash, see Additional Test Measurements.
CTest Coverage Step In a CTest Script, the ctest_coverage() command runs this step. Arguments to the command may specify some of the step settings.
CoverageCommand Command-line tool to perform software coverage analysis.  It will be executed in the location specified by the BuildDirectory setting.
• CTest Script variable: CTEST_COVERAGE_COMMAND
• CTest module variable: COVERAGE_COMMAND
CoverageExtraFlags Specify command-line options to the CoverageCommand tool.
• CTest Script variable: CTEST_COVERAGE_EXTRA_FLAGS
• CTest module variable: COVERAGE_EXTRA_FLAGS
These options are the first arguments passed to CoverageCommand.
CTest MemCheck Step In a CTest Script, the ctest_memcheck() command runs this step. Arguments to the command may specify some of the step settings.
MemoryCheckCommand Command-line tool to perform dynamic analysis.  Test command lines will be launched through this tool.
• CTest Script variable: CTEST_MEMORYCHECK_COMMAND
• CTest module variable: MEMORYCHECK_COMMAND
MemoryCheckCommandOptions Specify command-line options to the MemoryCheckCommand tool.  They will be placed prior to the test command line.
• CTest Script variable: CTEST_MEMORYCHECK_COMMAND_OPTIONS
• CTest module variable: MEMORYCHECK_COMMAND_OPTIONS
MemoryCheckType Specify the type of memory checking to perform.
• CTest Script variable: CTEST_MEMORYCHECK_TYPE
• CTest module variable: MEMORYCHECK_TYPE
MemoryCheckSanitizerOptions Specify options to sanitizers when running with a sanitize-enabled build.
• CTest Script variable: CTEST_MEMORYCHECK_SANITIZER_OPTIONS
• CTest module variable: MEMORYCHECK_SANITIZER_OPTIONS
MemoryCheckSuppressionFile Specify a file containing suppression rules for the MemoryCheckCommand tool.  It will be passed with options appropriate to the tool.
• CTest Script variable: CTEST_MEMORYCHECK_SUPPRESSIONS_FILE
• CTest module variable: MEMORYCHECK_SUPPRESSIONS_FILE
BoundsCheckerCommand Specify a MemoryCheckCommand that is known to be command-line compatible with Bounds Checker.
PurifyCommand Specify a MemoryCheckCommand that is known to be command-line compatible with Purify.
• CTest module variable: PURIFYCOMMAND
ValgrindCommand Specify a MemoryCheckCommand that is known to be command-line compatible with Valgrind.
• CTest module variable: VALGRIND_COMMAND
ValgrindCommandOptions Specify command-line options to the ValgrindCommand tool.  They will be placed prior to the test command line.
• CTest module variable: VALGRIND_COMMAND_OPTIONS
DrMemoryCommand Specify a MemoryCheckCommand that is known to be a command-line compatible with DrMemory.
• CTest module variable: DRMEMORY_COMMAND
DrMemoryCommandOptions Specify command-line options to the DrMemoryCommand tool.  They will be placed prior to the test command line.
• CTest module variable: DRMEMORY_COMMAND_OPTIONS
CudaSanitizerCommand Specify a MemoryCheckCommand that is known to be a command-line compatible with cuda-memcheck or compute-sanitizer.
• CTest module variable: CUDA_SANITIZER_COMMAND
CudaSanitizerCommandOptions Specify command-line options to the CudaSanitizerCommand tool. They will be placed prior to the test command line.
• CTest module variable: CUDA_SANITIZER_COMMAND_OPTIONS
CTest Submit Step In a CTest Script, the ctest_submit() command runs this step.  Arguments to the command may specify some of the step settings.
BuildName Describe the dashboard client platform with a short string. (Operating system, compiler, etc.)
• CTest Script variable: CTEST_BUILD_NAME
• CTest module variable: BUILDNAME
CDashVersion Legacy option.  Not used.
• CTest Script variable: none, detected from server
• CTest module variable: CTEST_CDASH_VERSION
CTestSubmitRetryCount Specify a number of attempts to retry submission on network failure.
• CTest Script variable: none, use the ctest_submit() RETRY_COUNT option.
• CTest module variable: CTEST_SUBMIT_RETRY_COUNT
CTestSubmitRetryDelay Specify a delay before retrying submission on network failure.
• CTest Script variable: none, use the ctest_submit() RETRY_DELAY option.
• CTest module variable: CTEST_SUBMIT_RETRY_DELAY
CurlOptions Specify a semicolon-separated list of options to control the Curl library that CTest uses internally to connect to the server. Possible options are CURLOPT_SSL_VERIFYPEER_OFF and CURLOPT_SSL_VERIFYHOST_OFF.
• CTest Script variable: CTEST_CURL_OPTIONS
• CTest module variable: CTEST_CURL_OPTIONS
DropLocation Legacy option.  When SubmitURL is not set, it is constructed from DropMethod, DropSiteUser, DropSitePassword, DropSite, and DropLocation.
• CTest Script variable: CTEST_DROP_LOCATION
• CTest module variable: DROP_LOCATION if set, else CTEST_DROP_LOCATION
DropMethod Legacy option.  When SubmitURL is not set, it is constructed from DropMethod, DropSiteUser, DropSitePassword, DropSite, and DropLocation.
• CTest Script variable: CTEST_DROP_METHOD
• CTest module variable: DROP_METHOD if set, else CTEST_DROP_METHOD
DropSite Legacy option.  When SubmitURL is not set, it is constructed from DropMethod, DropSiteUser, DropSitePassword, DropSite, and DropLocation.
• CTest Script variable: CTEST_DROP_SITE
• CTest module variable: DROP_SITE if set, else CTEST_DROP_SITE
DropSitePassword Legacy option.  When SubmitURL is not set, it is constructed from DropMethod, DropSiteUser, DropSitePassword, DropSite, and DropLocation.
• CTest Script variable: CTEST_DROP_SITE_PASSWORD
• CTest module variable: DROP_SITE_PASSWORD if set, else CTEST_DROP_SITE_PASWORD
DropSiteUser Legacy option.  When SubmitURL is not set, it is constructed from DropMethod, DropSiteUser, DropSitePassword, DropSite, and DropLocation.
• CTest Script variable: CTEST_DROP_SITE_USER
• CTest module variable: DROP_SITE_USER if set, else CTEST_DROP_SITE_USER
IsCDash Legacy option.  Not used.
• CTest Script variable: CTEST_DROP_SITE_CDASH
• CTest module variable: CTEST_DROP_SITE_CDASH
ScpCommand Legacy option.  Not used.
• CTest Script variable: CTEST_SCP_COMMAND
• CTest module variable: SCPCOMMAND
Site   Describe the dashboard client host site with a short string. (Hostname, domain, etc.)
• CTest Script variable: CTEST_SITE
• CTest module variable: SITE, initialized by the site_name() command
SubmitURL The http or https URL of the dashboard server to send the submission to.
• CTest Script variable: CTEST_SUBMIT_URL
• CTest module variable: SUBMIT_URL if set, else CTEST_SUBMIT_URL
TriggerSite Legacy option.  Not used.
• CTest Script variable: CTEST_TRIGGER_SITE
• CTest module variable: TRIGGER_SITE if set, else CTEST_TRIGGER_SITE
When the --show-only=json-v1 command line option is given, the test information is output in JSON format.  Version 1.0 of the JSON object model is defined as follows:
kind   The string "ctestInfo".
version A JSON object specifying the version components.  Its members are
major  A non-negative integer specifying the major version component.
minor  A non-negative integer specifying the minor version component.
backtraceGraph JSON object representing backtrace information with the following members:
commands List of command names.
files  List of file names.
nodes  List of node JSON objects with members:
command Index into the commands member of the backtraceGraph.
file   Index into the files member of the backtraceGraph.
line   Line number in the file where the backtrace was added.
parent Index into the nodes member of the backtraceGraph representing the parent in the graph.
tests  A JSON array listing information about each test.  Each entry is a JSON object with members:
name   Test name.
config Configuration that the test can run on.  Empty string means any config.
command List where the first element is the test command and the remaining elements are the command arguments.
backtrace Index into the nodes member of the backtraceGraph.
properties Test properties.  Can contain keys for each of the supported test properties.
CTest provides a mechanism for tests to specify the resources that they need in a fine-grained way, and for users to specify the resources available on the running machine. This allows CTest to internally keep track of which resources are in use and which are free, scheduling tests in a way that prevents them from trying to claim resources that are not available.
When the resource allocation feature is used, CTest will not oversubscribe resources. For example, if a resource has 8 slots, CTest will not run tests that collectively use more than 8 slots at a time. This has the effect of limiting how many tests can run at any given time, even if a high -j argument is used, if those tests all use some slots from the same resource.  In addition, it means that a single test that uses more of a resource than is available on a machine will not run at all (and will be reported as Not Run).
A common use case for this feature is for tests that require the use of a GPU.  Multiple tests can simultaneously allocate memory from a GPU, but if too many tests try to do this at once, some of them will fail to allocate, resulting in a failed test, even though the test would have succeeded if it had the memory it needed. By using the resource allocation feature, each test can specify how much memory it requires from a GPU, allowing CTest to schedule tests in a way that running several of these tests at once does not exhaust the GPU's memory pool.
Please note that CTest has no concept of what a GPU is or how much memory it has, nor does it have any way of communicating with a GPU to retrieve this information or perform any memory management. CTest simply keeps track of a list of abstract resource types, each of which has a certain number of slots available for tests to use. Each test specifies the number of slots that it requires from a certain resource, and CTest then schedules them in a way that prevents the total number of slots in use from exceeding the listed capacity.  When a test is executed, and slots from a resource are allocated to that test, tests may assume that they have exclusive use of those slots for the duration of the test's process.
The CTest resource allocation feature consists of two inputs:
• The resource specification file, described below, which describes the resources available on the system.
• The RESOURCE_GROUPS property of tests, which describes the resources required by the test.
When CTest runs a test, the resources allocated to that test are passed in the form of a set of environment variables as described below. Using this information to decide which resource to connect to is left to the test writer.
The RESOURCE_GROUPS property tells CTest what resources a test expects to use grouped in a way meaningful to the test.  The test itself must read the environment variables to determine which resources have been allocated to each group.  For example, each group may correspond to a process the test will spawn when executed.
Note that even if a test specifies a RESOURCE_GROUPS property, it is still possible for that to test to run without any resource allocation (and without the corresponding environment variables) if the user does not pass a resource specification file. Passing this file, either through the --resource-spec-file command-line argument or the RESOURCE_SPEC_FILE argument to ctest_test(), is what activates the resource allocation feature. Tests should check the CTEST_RESOURCE_GROUP_COUNT environment variable to find out whether or not resource allocation is activated. This variable will always (and only) be defined if resource allocation is activated. If resource allocation is not activated, then the CTEST_RESOURCE_GROUP_COUNT variable will not exist, even if it exists for the parent ctest process. If a test absolutely must have resource allocation, then it can return a failing exit code or use the SKIP_RETURN_CODE or SKIP_REGULAR_EXPRESSION properties to indicate a skipped test.
Resource Specification File The resource specification file is a JSON file which is passed to CTest, either on the ctest(1) command line as --resource-spec-file, or as the RESOURCE_SPEC_FILE argument of ctest_test(). If a dashboard script is used and RESOURCE_SPEC_FILE is not specified, the value of CTEST_RESOURCE_SPEC_FILE in the dashboard script is used instead.  If --resource-spec-file, RESOURCE_SPEC_FILE, and CTEST_RESOURCE_SPEC_FILE in the dashboard script are not specified, the value of CTEST_RESOURCE_SPEC_FILE in the CMake build is used instead. If none of these are specified, no resource spec file is used.
The resource specification file must be a JSON object. All examples in this document assume the following resource specification file:
{ "version": { "major": 1, "minor": 0 }, "local": [ { "gpus": [ { "id": "0", "slots": 2 }, { "id": "1", "slots": 4 }, { "id": "2", "slots": 2 }, { "id": "3" } ], "crypto_chips": [ { "id": "card0", "slots": 4 } ] } ] }
version An object containing a major integer field and a minor integer field.  Currently, the only supported version is major 1, minor 0. Any other value is an error.
local  A JSON array of resource sets present on the system.  Currently, this array is restricted to being of size 1.
Each array element is a JSON object with members whose names are equal to the desired resource types, such as gpus. These names must start with a lowercase letter or an underscore, and subsequent characters can be a lowercase letter, a digit, or an underscore. Uppercase letters are not allowed, because certain platforms have case-insensitive environment variables. See the Environment Variables section below for more information. It is recommended that the resource type name be the plural of a noun, such as gpus or crypto_chips (and not gpu or crypto_chip.)
Please note that the names gpus and crypto_chips are just examples, and CTest does not interpret them in any way. You are free to make up any resource type you want to meet your own requirements.
The value for each resource type is a JSON array consisting of JSON objects, each of which describe a specific instance of the specified resource. These objects have the following members:
id     A string consisting of an identifier for the resource. Each character in the identifier can be a lowercase letter, a digit, or an underscore.  Uppercase letters are not allowed.
Identifiers must be unique within a resource type. However, they do not have to be unique across resource types. For example, it is valid to have a gpus resource named 0 and a crypto_chips resource named 0, but not two gpus resources both named 0.
Please note that the IDs 0, 1, 2, 3, and card0 are just examples, and CTest does not interpret them in any way. You are free to make up any IDs you want to meet your own requirements.
slots  An optional unsigned number specifying the number of slots available on the resource. For example, this could be megabytes of RAM on a GPU, or cryptography units available on a cryptography chip. If slots is not specified, a default value of 1 is assumed.
In the example file above, there are four GPUs with ID's 0 through 3. GPU 0 has 2 slots, GPU 1 has 4, GPU 2 has 2, and GPU 3 has a default of 1 slot. There is also one cryptography chip with 4 slots.
RESOURCE_GROUPS Property See RESOURCE_GROUPS for a description of this property.
Environment Variables Once CTest has decided which resources to allocate to a test, it passes this information to the test executable as a series of environment variables. For each example below, we will assume that the test in question has a RESOURCE_GROUPS property of 2,gpus:2;gpus:4,gpus:1,crypto_chips:2.
The following variables are passed to the test process:
CTEST_RESOURCE_GROUP_COUNT The total number of groups specified by the RESOURCE_GROUPS property. For example:
• CTEST_RESOURCE_GROUP_COUNT=3
This variable will only be defined if ctest(1) has been given a --resource-spec-file, or if ctest_test() has been given a RESOURCE_SPEC_FILE. If no resource specification file has been given, this variable will not be defined.
CTEST_RESOURCE_GROUP_<num> The list of resource types allocated to each group, with each item separated by a comma. <num> is a number from zero to CTEST_RESOURCE_GROUP_COUNT minus one. CTEST_RESOURCE_GROUP_<num> is defined for each <num> in this range. For example:
• CTEST_RESOURCE_GROUP_0=gpus
• CTEST_RESOURCE_GROUP_1=gpus
• CTEST_RESOURCE_GROUP_2=crypto_chips,gpus
CTEST_RESOURCE_GROUP_<num>_<resource-type> The list of resource IDs and number of slots from each ID allocated to each group for a given resource type. This variable consists of a series of pairs, each pair separated by a semicolon, and with the two items in the pair separated by a comma. The first item in each pair is id: followed by the ID of a resource of type <resource-type>, and the second item is slots: followed by the number of slots from that resource allocated to the given group. For example:
• CTEST_RESOURCE_GROUP_0_GPUS=id:0,slots:2
• CTEST_RESOURCE_GROUP_1_GPUS=id:2,slots:2
• CTEST_RESOURCE_GROUP_2_GPUS=id:1,slots:4;id:3,slots:1
• CTEST_RESOURCE_GROUP_2_CRYPTO_CHIPS=id:card0,slots:2
In this example, group 0 gets 2 slots from GPU 0, group 1 gets 2 slots from GPU 2, and group 2 gets 4 slots from GPU 1, 1 slot from GPU 3, and 2 slots from cryptography chip card0.
<num> is a number from zero to CTEST_RESOURCE_GROUP_COUNT minus one.  <resource-type> is the name of a resource type, converted to uppercase.  CTEST_RESOURCE_GROUP_<num>_<resource-type> is defined for the product of each <num> in the range listed above and each resource type listed in CTEST_RESOURCE_GROUP_<num>.
Because some platforms have case-insensitive names for environment variables, the names of resource types may not clash in a case-insensitive environment.  Because of this, for the sake of simplicity, all resource types must be listed in all lowercase in the resource specification file and in the RESOURCE_GROUPS property, and they are converted to all uppercase in the CTEST_RESOURCE_GROUP_<num>_<resource-type> environment variable.
The following resources are available to get help using CMake:
Home Page https://cmake.org
The primary starting point for learning about CMake.
Online Documentation and Community Resources https://cmake.org/documentation
Links to available documentation and community resources may be found on this web page.
Discourse Forum https://discourse.cmake.org
The Discourse Forum hosts discussion and questions about CMake.
: https://cdash.org
2000-2021 Kitware, Inc. and Contributors
SIC(1)                       General Commands Manual                      SIC(1)
sic - simple irc client
sic [-h <host>] [-p <port>] [-n <nick>] [-k <keyword>] [-v]
sic is an extremly fast, small and simple irc client.  It reads commands from standard input and prints all server output to standard output. It multiplexes also all channel traffic into one output, that you don't have to switch different channel buffers, that's actually a feature.
-h <host> Overrides the default host (irc6.oftc.net)
-p <port> Overrides the default port (6667)
-n <nickname> Override the default nick ($USER)
-k <keyword> Specifies the keyword to authenticate your nick on the host
-v     Prints version information to standard output, then exits.
:j #channel Join a channel
:l #channel Leave a channel
:m #channel/user msg Write a message to #channel/user
:s #channel/user Set default channel/user
Everything which is not a command is simply send the server.
FMT(1)                            User Commands                           FMT(1)
fmt - simple optimal text formatter
fmt [-WIDTH] [OPTION]... [FILE]...
Reformat each paragraph in the FILE(s), writing to standard output.  The option -WIDTH is an abbreviated form of --width=DIGITS.
-c, --crown-margin preserve indentation of first two lines
-p, --prefix=STRING reformat only lines beginning with STRING, reattaching the prefix to reformatted lines
-s, --split-only split long lines, but do not refill
-t, --tagged-paragraph indentation of first line different from second
-u, --uniform-spacing one space between words, two after sentences
-w, --width=WIDTH maximum line width (default of 75 columns)
-g, --goal=WIDTH goal width (default of 93% of width)
Written by Ross Paterson.
Full documentation <https://www.gnu.org/software/coreutils/fmt> or available locally via: info '(coreutils) fmt invocation'
ASTYLE(1)                         User's Manual                        ASTYLE(1)
astyle - multi-language indentation and reformatting filters
astyle [options] File1 [File2] [...]
Artistic Style (or astyle) is a source code indenter, formatter and beautifier, written in C++. It handles the following programming languages:
•  C
•  C++
•  C++/CLI
•  Objective-C
•  C#
•  Java
For the full usage, please refer to the HTML documentation provided with this distribution in /usr/share/doc/astyle/html
Please note that when indenting a specific file the newly indented file retains the original filename, while a copy of the original file is created, with a suffix of ".orig" added to the original filename.
indent(1)
http://astyle.sourceforge.net/ http://www.sourceforge.net/projects/astyle/ http://packages.debian.org/astyle
Artistic Style was originally written by Tal Davidson <davidsont@bigfoot.com> and is currently maintained by Jim Pattee <jimp03@email.com>.
This stub manual page was written by Matteo Cypriani <mcy@lm7.fr> for the Debian project.
distccd(1)                   General Commands Manual                  distccd(1)
distccd - distributed C/C++ compiler server
distccd --daemon [OPTIONS]
distccd is the server for the distcc(1) distributed compiler.  It accepts and runs compilation jobs for network clients.
distcc can run over either TCP or a connection command such as ssh(1). TCP connections are fast but relatively insecure.  SSH connections are secure but slower.
For SSH connections, distccd must be installed on the volunteer but should not run as a daemon -- it will be started over SSH as needed.  SSH connections have several advantages: neither the client nor server listens on any new ports; compilations run with the privileges of the user that requested them; unauthorized users cannot access the server; and source and output is protected in transit.
For TCP connections, distccd can run either from an inetd-style program, or as a standalone server.  Standalone mode is recommended because it is slightly more efficient and allows distccd to regulate the number of incoming jobs.  The --listen and --allow options can be used for simple IP-based access control.
distcc may be started either by root or any other user.  If run by root, it gives away privileges and changes to the user specified by the --user option, or the user called "distcc", or the user called "nobody".
distccd does not have a configuration file; it's behaviour is controlled only by command-line options and requests from clients.
The recommended method for running distccd is as a standalone server. distccd will listen for network connections and fork several child processes to serve them.
If you installed distcc using a packaged version you may be able to start the server using the standard mechanism for your operating system, such as
# service distcc start
To start distccd as a standalone service, run a command like this either as root or an ordinary user:
# distccd --daemon
distccd may be run as a standalone daemon under the control of another program like init(8) or daemontools.  The super-server starts distccd when the system boots, and whenever it exits.
distccd should be started just as for a standalone server, except that the --no-detach option should be used so that the super-server can monitor it.
For example, to add distccd as a process to Linux sysvinit, add this line to /etc/inittab
dscc:2345:respawn:/usr/local/bin/distccd --verbose --no-detach --daemon
distccd may be started from a network super-server such as inetd or xinetd.  In this case inetd listens for network connections and invokes distccd when one arrives.
This is slightly less efficient than running a standalone distccd daemon. distccd is not able to regulate the number of concurrent jobs accepted, but there may be an option in your inetd configuration to do so.
For traditional Unix inetd, a line like this can be added to /etc/inetd.conf:
distcc stream tcp nowait.6000 root /usr/local/bin/distccd distccd --inetd
inetd imposes a limit on the rate of connections to a service to protect against accidental or intentional overuse.  The default in Linux NetKit inetd is 40 per minute, which is far  too low for distccd.  The .6000 option raises the limit to 6000 per minute.
To shut down a standalone server, send a SIGTERM signal to the parent process.  The most reliable way to do this from a script is to use the --pid-file option to record its process ID.  Shutting down the server in this way should allow any jobs currently in progress to complete.
--help Display summary usage information.
--version Shows the daemon version and exits.
-j, --jobs JOBS Sets a limit on the number of jobs that can be accepted at any time.  By default this is set to two greater than the number of CPUs on the machine, to allow for some processes being blocked on network IO.  (Daemon mode only.)
-N, --nice NICENESS Makes the daemon more nice about giving up the CPU to other tasks on the machine.  NICENESS is an increment to the current priority of the process.  The range of priorities depends on the operating system but is typically 0 to 20.  By default the niceness is increased by 5.
-p, --port PORT Set the TCP port to listen on, rather than the default of 3632. (Daemon mode only.)
--listen ADDRESS Instructs the distccd daemon to listen on the IP address ADDRESS. This can be useful for access control on dual-homed hosts. (Daemon mode only.)
-P, --pid-file FILE Save daemon process id to file FILE.  (Daemon mode only.)
--user USER If distccd gets executed as root, change to user USER.
-a, --allow IPADDR[/MASK] Instructs distccd to accept connections from the IP address IPADDR.  A CIDR mask length can be supplied optionally after a trailing slash, e.g. 192.168.0.0/24, in which case addresses that match in the most significant MASK bits will be allowed.  If no --allow options are specified, distccd will exit immediately! Unauthorized connections are rejected by closing the TCP connection immediately.  A warning is logged on the server but nothing is sent to the client.
--allow-private Allow private networks (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, and 127.0.0.0/8).
--job-lifetime SECONDS Kills a distccd job if it runs for more than SECONDS seconds. This prevents denial of service from clients that don't properly disconnect and compilers that fail to terminate. By default this is turned off.
--no-detach Do not detach from the shell that started the daemon.
--no-fork Don't fork children for each connection, to allow attaching gdb. Don't use this if you don't understand it!
--log-file FILE Send messages to file FILE instead of syslog.  Logging directly to a file is significantly faster than going via syslog and is recommended.
--log-level LEVEL Set the minimum severity of error that will be included in the log file.  Useful if you only want to see error messages rather than an entry for each connection.  LEVEL can be any of the standard syslog levels, and in particular critical, error, warning, notice, info, or debug.
--log-stderr Send log messages to stderr, rather than to a file or syslog. This is mainly intended for use in debugging.  Do not use in inetd mode.
--verbose Include debug messages in log.  Equivalent to --log-level=debug
--wizard Turn on all options appropriate for starting distccd under gdb: run as a daemon, log verbosely to stderr, and do not detach or fork.  For wizards only.
--stats Turn on the statistics HTTP server. By default it is off.  (Daemon mode only.)
--stats-port PORT Set the TCP port to listen on for HTTP requests, rather than the default of 3633.  (Daemon mode only.)
--inetd Serve a client connected to stdin/stdout.  As the name suggests, this option should be used when distccd is run from within a super-server like inetd.  distccd assumes inetd mode when stdin is a socket.
--daemon Bind and listen on a socket, rather than running from inetd.  This is used for standalone mode.  distccd assumes daemon mode at startup if stdin is a tty, so --daemon should be explicitly specified when starting distccd from a script or in a non- interactive ssh connection.
--enable-tcp-insecure By default (since Distcc 3.3) distcc will only execute binaries that are masqueraded to distcc in /usr/lib/distcc. This turns that off, and opens distcc up to executing arbitrary code. This feature is mainly for distcc's test suite. See MASQUERADING of distcc(1).
--zeroconf Register the availability of this distccd server using Avahi Zeroconf DNS Service Discovery (DNS-SD).  This allows distcc clients on the local network to access this distccd server without explicitly listing its host name or IP address in their distcc host list: the distcc clients can just use "+zeroconf" in their distcc host lists.  Can optionally use -j parameter to specify the maximum number of jobs that this server can process concurrently. This option is only available if distccd was compiled with Avahi support enabled.
--auth Perform GSS-API based mutual authentication.  This option is only available if distccd was compiled with the --with-auth configure option.
--show-principal Displays the name of the distccd security principal extracted from the environment.  This option is only available if distccd was compiled with the --with-auth configure option.
--blacklist=FILE Instruct distccd to reject connections from users whose principal names are listed in FILE.  This option is only available if distccd was compiled with the --with-auth configure option and if distccd is run with the --auth option.
--whitelist=FILE Instruct distccd to accept connections only from users whose principal names are listed in FILE.  This option is only available if distccd was compiled with the --with-auth configure option and if distccd is run with the --auth option.
distcc can pass either a relative or an absolute name for the compiler to distccd.  If distcc is given an explicit absolute compiler filename, that name is used verbatim on both the client and server.  If the compiler name is not an absolute path, or if the client is used in masquerade mode, then the server's PATH is searched.
distccd inherits its search path from its parent process.  By default distccd tries to remove directories that seem to contain distccd masquerade links, to guard against inadvertent recursion.  The DISTCCD_PATH environment variable may be used to set the path.
The search path is logged when --verbose is given.  In case of confusion, check the logs.
When distccd is run over ssh, the $HOME/.ssh/environment file may be useful in setting the path.  See ssh(1).
distccd logs messages to syslog's daemon facility by default, which normally writes to /var/log/daemon or /var/log/messages.  Log messages can be sent to a different file using the --log-file option.
DISTCC_CMDLIST If the environment variable DISTCC_CMDLIST is set, load a list of supported commands from the file named by DISTCC_CMDLIST, and refuse to serve any command whose last DISTCC_CMDLIST_MATCHWORDS last words do not match those of a command in that list.  See the comments in src/serve.c.
DISTCC_CMDLIST_NUMWORDS The number of words, from the end of the command, to match. The default is 1.
DISTCCD_PATH When starting distccd, if this value is set it will be used unaltered for the command-execution PATH.  The code that normally tries to remove masquerade directories from the path is skipped.
DISTCC_SAVE_TEMPS If set to 1, temporary files are not deleted after use.
Note that DISTCC_LOG does not affect the log destination for the server.
DISTCC_TCP_DEFER_ACCEPT On Linux, turn on the TCP_DEFER_ACCEPT socket option.  Defaults to on.
TMPDIR Directory for temporary files such as preprocessor output.  By default /tmp/ is used.
DISTCCD_PRINCIPAL If set, specifies the name of the principal that distccd runs under, and is used to authenticate with the client.  This environment variable is only used if distccd was compiled with the --with-auth configure option and if distccd is run with the --auth option.
distcc(1), pump(1), include_server(1), gcc(1), make(1), and  ccache(1) http://code.google.com/p/distcc/
IP-based access control is not secure against attackers able to spoof TCP connections, and cannot discriminate different users on a client.
TCP connections are not secure against attackers able to observe or modify network traffic.
Because ccache does not cache compilation from .i files, it is not useful to call it from distccd.
You are free to use distcc.  distcc (including this manual) may be copied, modified or distributed only under the terms of the GNU General Public Licence version 2 or later.  distcc comes with absolutely no warrany.  A copy of the GPL is included in the file COPYING.
distcc was written by Martin Pool <mbp@sourcefrog.net>, with the co- operation of many scholars including Wayne Davison, Frerich Raabe, Dimitri Papadopoulos and others noted in the NEWS file.  See pump(1) for the authors of pump mode.  Please report bugs to <distcc@lists.samba.org>.
KATE(1)                        Kate User's Manual                        KATE(1)
kate - Advanced text editor by KDE
kate [-s, --start name ] [--startanon] [--new-session] [-n, --new] [-b, --block] [-p, --pid pid] [-e, --encoding name] [-l, --line line] [-c, --column column] [-i, --stdin] [--tempfile] [file]
Kate is the KDE Advanced Text Editor.
Kate also provides the editor part for various applications, under the name KWrite.
Some of Kate's many features include configurable syntax highlighting for languages ranging from C and C++ to HTML to bash scripts, the ability to create and maintain projects, a multiple document interface (MDI), and a self-contained terminal emulator.
But Kate is more than a programmer's editor. Its ability to open several files at once makes it ideal for editing UNIXÂ®'s many configuration files. This document was written in Kate.
-s, --start name
Start Kate with a given session.
--startanon
Start Kate with a new anonymous session, implies -n (deprecated).
--new-session
Start Kate with a new anonymous session, implies -n.
-n, --new
Force start of a new Kate instance (is ignored if start is used and another Kate instance already has the given session opened), forced if no parameters and no URLs are given at all.
-b, --block
If using an already running Kate instance, block until it exits, if URLs given to open.
-p, --pid  pid
Only try to reuse kate instance with this pid (is ignored if start is used and another Kate instance already has the given session opened).
-e, --encoding  name
Set encoding for the file to open.
You can use this to force a file opened in utf-8 format, for instance. (The command iconv -l provides a list of encodings, which may be helpful to you.)
-l, --line  line
Navigate to this line.
-c, --column  column
Navigate to this column.
-i, --stdin
Read the contents of stdin.
--tempfile
The files/URLs opened by the application will be deleted after use.
File to open.
More detailed user documentation is available from help:/kate (either enter this URL into Konqueror, or run khelpcenter help:/kate). kf5options(7) qt5options(7) There is also further information available at the Kate website[1].
To open a file named source.cpp at column 15, line 25, in an existing Kate window, you could use:
kate -c 15 -l 25 source.cpp
If you have an active internet connection, you can take advantage of KDE's network transparency to open a file from an FTP site. If you do not have write permission on the remote server, the file will be opened read only and you will be prompted for a local filename to save to if you make changes. If you do have write permission, changes will be saved transparently over the network.
kate ftp://ftp.kde.org/pub/kde/README
The maintainer of Kate is Christoph Cullmann <cullmann@kde.org>. A comprehensive list of authors and contributors is available in the complete user manual mentioned above.
Lauri Watts <lauri@kde.org> Author.
1. Kate website https://kate-editor.org/
gh-release - Manage GitHub releases
gh release <command> [flags]
Manage GitHub releases
gh(1), gh-release-create(1), gh-release-delete(1), gh-release- download(1), gh-release-list(1), gh-release-upload(1), gh-release-view(1)
INFO(1)                           User Commands                          INFO(1)
info - read Info documents
info [OPTION]... [MENU-ITEM...]
Read documentation in Info format.
Frequently-used options: -a, --all use all matching manuals
-k, --apropos=STRING look up STRING in all indices of all manuals
-d, --directory=DIR add DIR to INFOPATH
-f, --file=MANUAL specify Info manual to visit
--index-search=STRING go to node pointed by index entry STRING
-n, --node=NODENAME specify nodes in first visited Info file
-o, --output=FILE output selected nodes to FILE
-O, --show-options, --usage go to command-line options node
--subnodes recursively output menu items
-v, --variable VAR=VALUE assign VALUE to Info variable VAR
-w, --where, --location print physical location of Info file
The first non-option argument, if present, is the menu entry to start from; it is searched for in all 'dir' files along INFOPATH.  If it is not present, info merges all 'dir' files and shows the result.  Any remaining arguments are treated as the names of menu items relative to the initial node visited.
For a summary of key bindings, type H within Info.
info   show top-level dir menu
info info-stnd show the manual for this Info program
info emacs start at emacs node from top-level dir
info emacs buffers select buffers menu entry in emacs manual
info emacs -n Files start at Files node within emacs manual
info '(emacs)Files' alternative way to start at Files node
info --show-options emacs start at node with emacs' command line options
info --subnodes -o out.txt emacs dump entire emacs manual to out.txt
info -f ./foo.info show file ./foo.info, not searching dir
Email bug reports to bug-texinfo@gnu.org, general questions and discussion to help-texinfo@gnu.org. Texinfo home page: http://www.gnu.org/software/texinfo/
Copyright Â© 2021 Free Software Foundation, Inc.  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it.  There is NO WARRANTY, to the extent permitted by law.
The full documentation for info is maintained as a Texinfo manual.  If the info program is properly installed at your site, the command
info info
should give you access to the complete manual.  (Or, if you have Emacs, M-x info will lead to the manual.)
GUILE(1)                          GNU Guile 2.2                         GUILE(1)
guile - The GNU Project Extension Language
guile [-L DIRECTORY] [-l FILE] [-e FUNCTION] [\] [-c EXPR] [-s SCRIPT] [--] [SCRIPT [ARGs for SCRIPT]]
Only the most useful options are listed here; see below for the remainder.
GNU Guile is an implementation of the Scheme programming language.  It extends the R5RS and R6RS language standards, providing additional features necessary for real-world use.
Guile works well for interactive use, basic scripting, and extension of larger applications, as well as for stand-alone Scheme application development.
The guile executable itself provides a stand-alone interactive compiler and run-time for Scheme programs, both for interactive use and for executing Scheme scripts or programs.
This manual page provides only brief instruction in invoking guile from the command line.  Please consult the Guile info documentation for more information, (type  info "(guile)Invoking Guile" at a command prompt).
-L DIRECTORY Add DIRECTORY to the front of Guile's module load path.
-l FILE Load Scheme source code from FILE.
-e FUNCTION After reading SCRIPT, apply FUNCTION to command-line arguments. Note that FUNCTION is evaluated, so, for example, (@ (my-module) my-proc) is valid here.
\      The "meta switch", used to work around limitations in #! scripts. See "The Meta Switch" in the texinfo documentation for more details.
--     Stop argument processing, and start guile in interactive mode.
-c EXPR Stop argument processing, and evaluate EXPR as a Scheme expression.