ctest.1.rst 59.3 KB
Newer Older
1
2
.. cmake-manual-description: CTest Command-Line Reference

3
4
5
ctest(1)
********

6
7
.. contents::

8
9
Synopsis
========
10

11
.. parsed-literal::
12

13
 ctest [<options>]
14
15
16
 ctest --build-and-test <path-to-source> <path-to-build>
       --build-generator <generator> [<options>...]
       [--build-options <opts>...] [--test-command <command> [<args>...]]
17
 ctest {-D <dashboard> | -M <model> -T <action> | -S <script> | -SP <script>}
18
       [-- <dashboard-options>...]
19

20
21
22
Description
===========

23
The **ctest** executable is the CMake test driver program.
24
CMake-generated build trees created for projects that use the
25
26
:command:`enable_testing` and :command:`add_test` commands have testing support.
This program will run the tests and report results.
27

28
29
.. _`CTest Options`:

30
31
Options
=======
32

33
``--preset <preset>``, ``--preset=<preset>``
34
35
36
37
38
39
40
41
42
 Use a test preset to specify test options. The project binary directory
 is inferred from the ``configurePreset`` key. The current working directory
 must contain CMake preset files.
 See :manual:`preset <cmake-presets(7)>` for more details.

``--list-presets``
 Lists the available test presets. The current working directory must contain
 CMake preset files.

43
44
``-C <cfg>, --build-config <cfg>``
 Choose configuration to test.
45

46
47
 Some CMake-generated build trees can have multiple build
 configurations in the same tree.  This option can be used to specify
48
49
 which one should be tested.  Example configurations are ``Debug`` and
 ``Release``.
50

51
52
53
``--progress``
 Enable short progress output from tests.

54
 When the output of **ctest** is being sent directly to a terminal, the
55
56
57
58
59
60
61
62
63
 progress through the set of tests is reported by updating the same line
 rather than printing start and end messages for each test on new lines.
 This can significantly reduce the verbosity of the test output.
 Test completion messages are still output on their own line for failed
 tests and the final test summary will also still be logged.

 This option can also be enabled by setting the environment variable
 :envvar:`CTEST_PROGRESS_OUTPUT`.

64
65
``-V,--verbose``
 Enable verbose output from tests.
66

67
68
 Test output is normally suppressed and only summary information is
 displayed.  This option will show all test output.
69

70
71
``-VV,--extra-verbose``
 Enable more verbose output from tests.
72

73
74
 Test output is normally suppressed and only summary information is
 displayed.  This option will show even more test output.
75

76
77
``--debug``
 Displaying more verbose internals of CTest.
78

79
80
 This feature will result in a large number of output that is mostly
 useful for debugging dashboard problems.
81

82
``--output-on-failure``
83
 Output anything outputted by the test program if the test should fail.
84
85
 This option can also be enabled by setting the
 :envvar:`CTEST_OUTPUT_ON_FAILURE` environment variable
86

87
88
89
``--stop-on-failure``
 Stop running the tests when the first failure happens.

90
91
``-F``
 Enable failover.
92

93
 This option allows CTest to resume a test set execution that was
94
 previously interrupted.  If no interruption occurred, the ``-F`` option
95
 will have no effect.
96

97
``-j <jobs>, --parallel <jobs>``
98
 Run the tests in parallel using the given number of jobs.
99

100
101
 This option tells CTest to run the tests in parallel using given
 number of jobs. This option can also be set by setting the
102
 :envvar:`CTEST_PARALLEL_LEVEL` environment variable.
103

104
105
106
107
 This option can be used with the :prop_test:`PROCESSORS` test property.

 See `Label and Subproject Summary`_.

108
109
``--resource-spec-file <file>``
 Run CTest with :ref:`resource allocation <ctest-resource-allocation>` enabled,
110
 using the
111
 :ref:`resource specification file <ctest-resource-specification-file>`
112
113
114
 specified in ``<file>``.

 When ``ctest`` is run as a `Dashboard Client`_ this sets the
115
 ``ResourceSpecFile`` option of the `CTest Test Step`_.
116

117
118
119
120
121
122
123
``--test-load <level>``
 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.

 When ``ctest`` is run as a `Dashboard Client`_ this sets the
 ``TestLoad`` option of the `CTest Test Step`_.

124
``-Q,--quiet``
125
 Make CTest quiet.
126

127
 This option will suppress all the output.  The output log file will
128
129
130
 still be generated if the ``--output-log`` is specified.  Options such
 as ``--verbose``, ``--extra-verbose``, and ``--debug`` are ignored
 if ``--quiet`` is specified.
131

132
``-O <file>, --output-log <file>``
133
 Output to log file.
134

135
 This option tells CTest to write all its output to a ``<file>`` log file.
136

137
138
139
140
141
142
``--output-junit <file>``
 Write test results in JUnit format.

 This option tells CTest to write test results to a ``<file>`` JUnit XML file.
 If ``<file>`` already exists it will be overwritten.

143
``-N,--show-only[=<format>]``
144
 Disable actual execution of tests.
145

146
 This option tells CTest to list the tests that would be run but not
147
 actually run them.  Useful in conjunction with the ``-R`` and ``-E``
148
 options.
149

150
151
152
153
154
155
156
157
158
159
 ``<format>`` can be one of the following values.

   ``human``
     Human-friendly output.  This is not guaranteed to be stable.
     This is the default.

   ``json-v1``
     Dump the test information in JSON format.
     See `Show as JSON Object Model`_.

160
161
``-L <regex>, --label-regex <regex>``
 Run tests with labels matching regular expression.
162

163
 This option tells CTest to run only the tests whose labels match the
164
165
166
167
 given regular expression.  When more than one ``-L`` option is given,
 a test will only be run if each regular expression matches at least one
 of the test's labels (i.e. the multiple ``-L`` labels form an ``AND``
 relationship).  See `Label Matching`_.
168

169
170
``-R <regex>, --tests-regex <regex>``
 Run tests matching regular expression.
171

172
 This option tells CTest to run only the tests whose names match the
173
 given regular expression.
174

175
176
``-E <regex>, --exclude-regex <regex>``
 Exclude tests matching regular expression.
177

178
 This option tells CTest to NOT run the tests whose names match the
179
 given regular expression.
180

181
182
``-LE <regex>, --label-exclude <regex>``
 Exclude tests with labels matching regular expression.
183

184
 This option tells CTest to NOT run the tests whose labels match the
185
186
187
188
 given regular expression.  When more than one ``-LE`` option is given,
 a test will only be excluded if each regular expression matches at least one
 of the test's labels (i.e. the multiple ``-LE`` labels form an ``AND``
 relationship).  See `Label Matching`_.
189

190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
``-FA <regex>, --fixture-exclude-any <regex>``
 Exclude fixtures matching ``<regex>`` from automatically adding any tests to
 the test set.

 If a test in the set of tests to be executed requires a particular fixture,
 that fixture's setup and cleanup tests would normally be added to the test set
 automatically. This option prevents adding setup or cleanup tests for fixtures
 matching the ``<regex>``. Note that all other fixture behavior is retained,
 including test dependencies and skipping tests that have fixture setup tests
 that fail.

``-FS <regex>, --fixture-exclude-setup <regex>``
 Same as ``-FA`` except only matching setup tests are excluded.

``-FC <regex>, --fixture-exclude-cleanup <regex>``
 Same as ``-FA`` except only matching cleanup tests are excluded.

207
``-D <dashboard>, --dashboard <dashboard>``
208
 Execute dashboard test.
209

210
 This option tells CTest to act as a CDash client and perform a
211
212
213
214
 dashboard test.  All tests are ``<Mode><Test>``, where ``<Mode>`` can be
 ``Experimental``, ``Nightly``, and ``Continuous``, and ``<Test>`` can be
 ``Start``, ``Update``, ``Configure``, ``Build``, ``Test``,
 ``Coverage``, and ``Submit``.
215

216
217
 See `Dashboard Client`_.

218
``-D <var>:<type>=<value>``
219
 Define a variable for script mode.
220

221
 Pass in variable values on the command line.  Use in conjunction
222
 with ``-S`` to pass variable values to a dashboard script.  Parsing ``-D``
223
 arguments as variable values is only attempted if the value
224
 following ``-D`` does not match any of the known dashboard types.
225

226
``-M <model>, --test-model <model>``
227
 Sets the model for a dashboard.
228

229
 This option tells CTest to act as a CDash client where the ``<model>``
230
231
 can be ``Experimental``, ``Nightly``, and ``Continuous``.
 Combining ``-M`` and ``-T`` is similar to ``-D``.
232

233
234
 See `Dashboard Client`_.

235
``-T <action>, --test-action <action>``
236
 Sets the dashboard action to perform.
237

238
 This option tells CTest to act as a CDash client and perform some
239
240
241
 action such as ``start``, ``build``, ``test`` etc. See
 `Dashboard Client Steps`_ for the full list of actions.
 Combining ``-M`` and ``-T`` is similar to ``-D``.
242

243
 See `Dashboard Client`_.
244

245
``-S <script>, --script <script>``
246
 Execute a dashboard for a configuration.
247

248
 This option tells CTest to load in a configuration script which sets
249
 a number of parameters such as the binary and source directories.
250
 Then CTest will do what is required to create and run a dashboard.
251
 This option basically sets up a dashboard and then runs ``ctest -D``
252
 with the appropriate options.
253

254
255
 See `Dashboard Client`_.

256
``-SP <script>, --script-new-process <script>``
257
 Execute a dashboard for a configuration.
258

259
 This option does the same operations as ``-S`` but it will do them in a
260
261
 separate process.  This is primarily useful in cases where the
 script may modify the environment and you do not want the modified
262
 environment to impact other ``-S`` scripts.
263

264
 See `Dashboard Client`_.
265

266
267
``-I [Start,End,Stride,test#,test#|Test file], --tests-information``
 Run a specific number of tests by number.
268

269
270
271
272
 This option causes CTest to run tests starting at number ``Start``,
 ending at number ``End``, and incrementing by ``Stride``.  Any additional
 numbers after ``Stride`` are considered individual test numbers.  ``Start``,
 ``End``, or ``Stride`` can be empty.  Optionally a file can be given that
273
 contains the same syntax as the command line.
274

275
``-U, --union``
276
 Take the Union of ``-I`` and ``-R``.
277

278
279
 When both ``-R`` and ``-I`` are specified by default the intersection of
 tests are run.  By specifying ``-U`` the union of tests is run instead.
280

281
``--rerun-failed``
282
 Run only the tests that failed previously.
283

284
285
 This option tells CTest to perform only the tests that failed during
 its previous run.  When this option is specified, CTest ignores all
286
287
 other options intended to modify the list of tests to run (``-L``, ``-R``,
 ``-E``, ``-LE``, ``-I``, etc).  In the event that CTest runs and no tests
288
 fail, subsequent calls to CTest with the ``--rerun-failed`` option will run
289
 the set of tests that most recently failed (if any).
290

291
292
293
``--repeat <mode>:<n>``
  Run tests repeatedly based on the given ``<mode>`` up to ``<n>`` times.
  The modes are:
294

295
296
297
  ``until-fail``
    Require each test to run ``<n>`` times without failing in order to pass.
    This is useful in finding sporadic failures in test cases.
298

299
300
301
302
  ``until-pass``
    Allow each test to run up to ``<n>`` times in order to pass.
    Repeats tests if they fail for any reason.
    This is useful in tolerating sporadic failures in test cases.
303

304
305
306
307
308
  ``after-timeout``
    Allow each test to run up to ``<n>`` times in order to pass.
    Repeats tests only if they timeout.
    This is useful in tolerating sporadic timeouts in test cases
    on busy machines.
309

310
311
``--repeat-until-fail <n>``
 Equivalent to ``--repeat until-fail:<n>``.
312

313
``--max-width <width>``
314
 Set the max width for a test name to output.
315

316
317
318
 Set the maximum width for each test name to show in the output.
 This allows the user to widen the output to avoid clipping the test
 name which can be very annoying.
319

320
``--interactive-debug-mode [0|1]``
321
 Set the interactive mode to ``0`` or ``1``.
322

323
 This option causes CTest to run tests in either an interactive mode
324
325
 or a non-interactive mode.  On Windows this means that in
 non-interactive mode, all system debug pop up windows are blocked.
326
 In dashboard mode (``Experimental``, ``Nightly``, ``Continuous``), the default
327
328
 is non-interactive.  When just running tests not for a dashboard the
 default is to allow popups and interactive debugging.
329

330
331
``--no-label-summary``
 Disable timing summary information for labels.
332

333
 This option tells CTest not to print summary information for each
334
335
 label associated with the tests run.  If there are no labels on the
 tests, nothing extra is printed.
336

337
338
 See `Label and Subproject Summary`_.

339
``--no-subproject-summary``
340
341
 Disable timing summary information for subprojects.

342
 This option tells CTest not to print summary information for each
343
344
345
 subproject associated with the tests run.  If there are no subprojects on the
 tests, nothing extra is printed.

346
347
 See `Label and Subproject Summary`_.

348
349
350
``--build-and-test``
See `Build and Test Mode`_.

351
352
353
``--test-dir <dir>``
Specify the directory in which to look for tests.

354
355
356
357
358
359
360
361
362
``--test-output-size-passed <size>``
 Limit the output for passed tests to ``<size>`` bytes.

``--test-output-size-failed <size>``
 Limit the output for failed tests to ``<size>`` bytes.

``--overwrite``
 Overwrite CTest configuration option.

363
 By default CTest uses configuration options from configuration file.
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
 This option will overwrite the configuration option.

``--force-new-ctest-process``
 Run child CTest instances as new processes.

 By default CTest will run child CTest instances within the same
 process.  If this behavior is not desired, this argument will
 enforce new processes for child CTest processes.

``--schedule-random``
 Use a random order for scheduling tests.

 This option will run the tests in a random order.  It is commonly
 used to detect implicit dependencies in a test suite.

``--submit-index``
 Legacy option for old Dart2 dashboard server feature.
 Do not use.

``--timeout <seconds>``
384
 Set the default test timeout.
385

386
387
388
 This option effectively sets a timeout on all tests that do not
 already have a timeout set on them via the :prop_test:`TIMEOUT`
 property.
389
390
391
392
393
394
395
396
397
398
399
400
401
402

``--stop-time <time>``
 Set a time at which all tests should stop running.

 Set a real time of day at which all tests should timeout.  Example:
 ``7:00:00 -0400``.  Any time format understood by the curl date parser
 is accepted.  Local time is assumed if no timezone is specified.

``--print-labels``
 Print all available test labels.

 This option will not run any tests, it will simply print the list of
 all labels associated with the test set.

403
404
405
406
407
408
409
410
``--no-tests=<[error|ignore]>``
 Regard no tests found either as error or ignore it.

 If no tests were found, the default behavior of CTest is to always log an
 error message but to return an error code in script mode only.  This option
 unifies the behavior of CTest by either returning an error code if no tests
 were found or by ignoring it.

411
412
.. include:: OPTIONS_HELP.txt

413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
.. _`Label Matching`:

Label Matching
==============

Tests may have labels attached to them. Tests may be included
or excluded from a test run by filtering on the labels.
Each individual filter is a regular expression applied to
the labels attached to a test.

When ``-L`` is used, in order for a test to be included in a
test run, each regular expression must match at least one
label.  Using more than one ``-L`` option means "match **all**
of these".

The ``-LE`` option works just like ``-L``, but excludes tests
rather than including them. A test is excluded if each regular
expression matches at least one label.

If a test has no labels attached to it, then ``-L`` will never
include that test, and ``-LE`` will never exclude that test.
As an example of tests with labels, consider five tests,
with the following labels:

* *test1* has labels *tuesday* and *production*
* *test2* has labels *tuesday* and *test*
* *test3* has labels *wednesday* and *production*
* *test4* has label *wednesday*
* *test5* has labels *friday* and *test*

Running ``ctest`` with ``-L tuesday -L test`` will select *test2*, which has
both labels. Running CTest with ``-L test`` will select *test2* and
*test5*, because both of them have a label that matches that regular
expression.

Because the matching works with regular expressions, take note that
running CTest with ``-L es`` will match all five tests.
To select the *tuesday* and *wednesday* tests together, use a single
regular expression that matches either of them, like ``-L "tue|wed"``.

453
454
455
456
457
.. _`Label and Subproject Summary`:

Label and Subproject Summary
============================

458
CTest prints timing summary information for each ``LABEL`` and subproject
459
460
461
462
associated with the tests run. The label time summary will not include labels
that are mapped to subprojects.

When the :prop_test:`PROCESSORS` test property is set, CTest will display a
463
weighted test timing result in label and subproject summaries. The time is
464
465
reported with `sec*proc` instead of just `sec`.

466
467
The weighted time summary reported for each label or subproject ``j``
is computed as::
468
469
470
471
472
473
474
475

  Weighted Time Summary for Label/Subproject j =
      sum(raw_test_time[j,i] * num_processors[j,i], i=1...num_tests[j])

  for labels/subprojects j=1...total

where:

476
477
* ``raw_test_time[j,i]``: Wall-clock time for the ``i`` test
  for the ``j`` label or subproject
478
* ``num_processors[j,i]``: Value of the CTest :prop_test:`PROCESSORS` property
479
480
  for the ``i`` test for the ``j`` label or subproject
* ``num_tests[j]``: Number of tests associated with the ``j`` label or subproject
481
* ``total``: Total number of labels or subprojects that have at least one test run
482
483
484
485
486
487

Therefore, the weighted time summary for each label or subproject represents
the amount of time that CTest gave to run the tests for each label or
subproject and gives a good representation of the total expense of the tests
for each label or subproject when compared to other labels or subprojects.

488
489
490
For example, if ``SubprojectA`` showed ``100 sec*proc`` and ``SubprojectB`` showed
``10 sec*proc``, then CTest allocated approximately 10 times the CPU/core time
to run the tests for ``SubprojectA`` than for ``SubprojectB`` (e.g. so if effort
491
is going to be expended to reduce the cost of the test suite for the whole
492
project, then reducing the cost of the test suite for ``SubprojectA`` would
493
likely have a larger impact than effort to reduce the cost of the test suite
494
for ``SubprojectB``).
495

496
.. _`Build and Test Mode`:
497

498
499
500
Build and Test Mode
===================

501
502
CTest provides a command-line signature to configure (i.e. run cmake on),
build, and/or execute a test::
503
504

  ctest --build-and-test <path-to-source> <path-to-build>
505
506
507
508
        --build-generator <generator>
        [<options>...]
        [--build-options <opts>...]
        [--test-command <command> [<args>...]]
509
510

The configure and test steps are optional. The arguments to this command line
511
are the source and binary directories.  The ``--build-generator`` option *must*
512
513
514
be provided to use ``--build-and-test``.  If ``--test-command`` is specified
then that will be run after the build is complete.  Other options that affect
this mode include:
515

516
517
``--build-target``
 Specify a specific target to build.
518

519
 If left out the ``all`` target is built.
520

521
522
``--build-nocmake``
 Run the build without running cmake first.
523

524
 Skip the cmake step.
525

526
527
``--build-run-dir``
 Specify directory to run programs from.
528

529
 Directory where programs will be after it has been compiled.
530

531
``--build-two-config``
532
 Run CMake twice.
533

534
535
``--build-exe-dir``
 Specify the directory for the executable.
536

537
``--build-generator``
538
 Specify the generator to use. See the :manual:`cmake-generators(7)` manual.
539

540
541
542
``--build-generator-platform``
 Specify the generator-specific platform.

543
544
``--build-generator-toolset``
 Specify the generator-specific toolset.
545

546
547
``--build-project``
 Specify the name of the project to build.
548

549
``--build-makeprogram``
550
551
 Specify the explicit make program to be used by CMake when configuring and
 building the project. Only applicable for Make and Ninja based generators.
552

553
554
``--build-noclean``
 Skip the make clean step.
555

556
557
``--build-config-sample``
 A sample executable to use to determine the configuration that
558
 should be used.  e.g.  ``Debug``, ``Release`` etc.
559

560
``--build-options``
561
562
563
564
 Additional options for configuring the build (i.e. for CMake, not for
 the build tool).  Note that if this is specified, the ``--build-options``
 keyword and its arguments must be the last option given on the command
 line, with the possible exception of ``--test-command``.
565

566
``--test-command``
567
568
569
 The command to run as the test step with the ``--build-and-test`` option.
 All arguments following this keyword will be assumed to be part of the
 test command line, so it must be the last option given.
570

571
``--test-timeout``
572
 The time limit in seconds
573

574
.. _`Dashboard Client`:
575

576
577
Dashboard Client
================
578

579
580
581
582
CTest can operate as a client for the `CDash`_ software quality dashboard
application.  As a dashboard client, CTest performs a sequence of steps
to configure, build, and test software, and then submits the results to
a `CDash`_ server. The command-line signature used to submit to `CDash`_ is::
583

584
585
  ctest (-D <dashboard> | -M <model> -T <action> | -S <script> | -SP <script>)
        [-- <dashboard-options>...]
586

587
Options for Dashboard Client include:
588

Zack Galbreath's avatar
Zack Galbreath committed
589
590
``--group <group>``
 Specify what group you'd like to submit results to
591

Zack Galbreath's avatar
Zack Galbreath committed
592
 Submit dashboard to specified group instead of default one.  By
593
 default, the dashboard is submitted to Nightly, Experimental, or
Zack Galbreath's avatar
Zack Galbreath committed
594
 Continuous group, but by specifying this option, the group can be
595
 arbitrary.
596

Zack Galbreath's avatar
Zack Galbreath committed
597
598
599
 This replaces the deprecated option ``--track``.
 Despite the name change its behavior is unchanged.

600
601
``-A <file>, --add-notes <file>``
 Add a notes file with submission.
602

603
 This option tells CTest to include a notes file when submitting
604
 dashboard.
605

606
``--tomorrow-tag``
607
 ``Nightly`` or ``Experimental`` starts with next day tag.
608

609
 This is useful if the build will not finish in one day.
610

611
612
``--extra-submit <file>[;<file>]``
 Submit extra files to the dashboard.
613

614
 This option will submit extra files to the dashboard.
615

616
``--http1.0``
617
 Submit using `HTTP 1.0`.
618

619
620
 This option will force CTest to use `HTTP 1.0` to submit files to the
 dashboard, instead of `HTTP 1.1`.
621

622
623
``--no-compress-output``
 Do not compress test output when submitting.
624

625
626
627
 This flag will turn off automatic compression of test output.  Use
 this to maintain compatibility with an older version of CDash which
 doesn't support compressed test output.
628

629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
Dashboard Client Steps
----------------------

CTest defines an ordered list of testing steps of which some or all may
be run as a dashboard client:

``Start``
  Start a new dashboard submission to be composed of results recorded
  by the following steps.
  See the `CTest Start Step`_ section below.

``Update``
  Update the source tree from its version control repository.
  Record the old and new versions and the list of updated source files.
  See the `CTest Update Step`_ section below.

``Configure``
  Configure the software by running a command in the build tree.
  Record the configuration output log.
  See the `CTest Configure Step`_ section below.

``Build``
  Build the software by running a command in the build tree.
  Record the build output log and detect warnings and errors.
  See the `CTest Build Step`_ section below.

``Test``
  Test the software by loading a ``CTestTestfile.cmake``
  from the build tree and executing the defined tests.
  Record the output and result of each test.
  See the `CTest Test Step`_ section below.

``Coverage``
  Compute coverage of the source code by running a coverage
  analysis tool and recording its output.
  See the `CTest Coverage Step`_ section below.

``MemCheck``
  Run the software test suite through a memory check tool.
  Record the test output, results, and issues reported by the tool.
  See the `CTest MemCheck Step`_ section below.

``Submit``
  Submit results recorded from other testing steps to the
  software quality dashboard server.
  See the `CTest Submit Step`_ section below.

Dashboard Client Modes
----------------------

CTest defines three modes of operation as a dashboard client:

``Nightly``
  This mode is intended to be invoked once per day, typically at night.
  It enables the ``Start``, ``Update``, ``Configure``, ``Build``, ``Test``,
  ``Coverage``, and ``Submit`` steps by default.  Selected steps run even
  if the ``Update`` step reports no changes to the source tree.

``Continuous``
  This mode is intended to be invoked repeatedly throughout the day.
  It enables the ``Start``, ``Update``, ``Configure``, ``Build``, ``Test``,
  ``Coverage``, and ``Submit`` steps by default, but exits after the
  ``Update`` step if it reports no changes to the source tree.

``Experimental``
  This mode is intended to be invoked by a developer to test local changes.
  It enables the ``Start``, ``Configure``, ``Build``, ``Test``, ``Coverage``,
  and ``Submit`` steps by default.

Dashboard Client via CTest Command-Line
---------------------------------------

CTest can perform testing on an already-generated build tree.
Run the ``ctest`` command with the current working directory set
to the build tree and use one of these signatures::

  ctest -D <mode>[<step>]
  ctest -M <mode> [ -T <step> ]...

The ``<mode>`` must be one of the above `Dashboard Client Modes`_,
and each ``<step>`` must be one of the above `Dashboard Client Steps`_.

CTest reads the `Dashboard Client Configuration`_ settings from
a file in the build tree called either ``CTestConfiguration.ini``
or ``DartConfiguration.tcl`` (the names are historical).  The format
of the file is::

  # Lines starting in '#' are comments.
  # Other non-blank lines are key-value pairs.
  <setting>: <value>

where ``<setting>`` is the setting name and ``<value>`` is the
setting value.

In build trees generated by CMake, this configuration file is
generated by the :module:`CTest` module if included by the project.
The module uses variables to obtain a value for each setting
as documented with the settings below.

.. _`CTest Script`:

Dashboard Client via CTest Script
---------------------------------

CTest can perform testing driven by a :manual:`cmake-language(7)`
script that creates and maintains the source and build tree as
well as performing the testing steps.  Run the ``ctest`` command
with the current working directory set outside of any build tree
and use one of these signatures::

  ctest -S <script>
  ctest -SP <script>

The ``<script>`` file must call :ref:`CTest Commands` commands
to run testing steps explicitly as documented below.  The commands
obtain `Dashboard Client Configuration`_ settings from their
arguments or from variables set in the script.

Dashboard Client Configuration
==============================

The `Dashboard Client Steps`_ may be configured by named
settings as documented in the following sections.

.. _`CTest Start Step`:

CTest Start Step
----------------

Start a new dashboard submission to be composed of results recorded
by the following steps.

In a `CTest Script`_, the :command:`ctest_start` command runs this step.
Arguments to the command may specify some of the step settings.
The command first runs the command-line specified by the
``CTEST_CHECKOUT_COMMAND`` variable, if set, to initialize the source
directory.

Configuration settings include:

``BuildDirectory``
  The full path to the project build tree.

772
  * `CTest Script`_ variable: :variable:`CTEST_BINARY_DIRECTORY`
773
774
775
776
777
  * :module:`CTest` module variable: :variable:`PROJECT_BINARY_DIR`

``SourceDirectory``
  The full path to the project source tree.

778
  * `CTest Script`_ variable: :variable:`CTEST_SOURCE_DIRECTORY`
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
  * :module:`CTest` module variable: :variable:`PROJECT_SOURCE_DIR`

.. _`CTest Update Step`:

CTest Update Step
-----------------

In a `CTest Script`_, the :command:`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.

794
  * `CTest Script`_ variable: :variable:`CTEST_BZR_COMMAND`
795
796
797
798
799
  * :module:`CTest` module variable: none

``BZRUpdateOptions``
  Command-line options to the ``BZRCommand`` when updating the source.

800
  * `CTest Script`_ variable: :variable:`CTEST_BZR_UPDATE_OPTIONS`
801
802
803
804
805
  * :module:`CTest` module variable: none

``CVSCommand``
  ``cvs`` command-line tool to use if source tree is managed by CVS.

806
  * `CTest Script`_ variable: :variable:`CTEST_CVS_COMMAND`
807
808
809
810
811
  * :module:`CTest` module variable: ``CVSCOMMAND``

``CVSUpdateOptions``
  Command-line options to the ``CVSCommand`` when updating the source.

812
  * `CTest Script`_ variable: :variable:`CTEST_CVS_UPDATE_OPTIONS`
813
814
815
816
817
  * :module:`CTest` module variable: ``CVS_UPDATE_OPTIONS``

``GITCommand``
  ``git`` command-line tool to use if source tree is managed by Git.

818
  * `CTest Script`_ variable: :variable:`CTEST_GIT_COMMAND`
819
820
  * :module:`CTest` module variable: ``GITCOMMAND``

821
822
  The source tree is updated by ``git fetch`` followed by
  ``git reset --hard`` to the ``FETCH_HEAD``.  The result is the same
823
  as ``git pull`` except that any local modifications are overwritten.
824
825
  Use ``GITUpdateCustom`` to specify a different approach.

826
827
828
829
830
831
``GITInitSubmodules``
  If set, CTest will update the repository's submodules before updating.

  * `CTest Script`_ variable: :variable:`CTEST_GIT_INIT_SUBMODULES`
  * :module:`CTest` module variable: ``CTEST_GIT_INIT_SUBMODULES``

832
``GITUpdateCustom``
833
  Specify a custom command line (as a semicolon-separated list) to run
834
835
836
  in the source tree (Git work tree) to update it instead of running
  the ``GITCommand``.

837
  * `CTest Script`_ variable: :variable:`CTEST_GIT_UPDATE_CUSTOM`
838
839
840
841
842
  * :module:`CTest` module variable: ``CTEST_GIT_UPDATE_CUSTOM``

``GITUpdateOptions``
  Command-line options to the ``GITCommand`` when updating the source.

843
  * `CTest Script`_ variable: :variable:`CTEST_GIT_UPDATE_OPTIONS`
844
845
846
847
848
  * :module:`CTest` module variable: ``GIT_UPDATE_OPTIONS``

``HGCommand``
  ``hg`` command-line tool to use if source tree is managed by Mercurial.

849
  * `CTest Script`_ variable: :variable:`CTEST_HG_COMMAND`
850
851
852
853
854
  * :module:`CTest` module variable: none

``HGUpdateOptions``
  Command-line options to the ``HGCommand`` when updating the source.

855
  * `CTest Script`_ variable: :variable:`CTEST_HG_UPDATE_OPTIONS`
856
857
858
859
860
  * :module:`CTest` module variable: none

``P4Client``
  Value of the ``-c`` option to the ``P4Command``.

861
  * `CTest Script`_ variable: :variable:`CTEST_P4_CLIENT`
862
863
864
865
866
  * :module:`CTest` module variable: ``CTEST_P4_CLIENT``

``P4Command``
  ``p4`` command-line tool to use if source tree is managed by Perforce.

867
  * `CTest Script`_ variable: :variable:`CTEST_P4_COMMAND`
868
869
870
871
872
  * :module:`CTest` module variable: ``P4COMMAND``

``P4Options``
  Command-line options to the ``P4Command`` for all invocations.

873
  * `CTest Script`_ variable: :variable:`CTEST_P4_OPTIONS`
874
875
876
  * :module:`CTest` module variable: ``CTEST_P4_OPTIONS``

``P4UpdateCustom``
877
  Specify a custom command line (as a semicolon-separated list) to run
878
879
880
881
882
883
884
885
886
  in the source tree (Perforce tree) to update it instead of running
  the ``P4Command``.

  * `CTest Script`_ variable: none
  * :module:`CTest` module variable: ``CTEST_P4_UPDATE_CUSTOM``

``P4UpdateOptions``
  Command-line options to the ``P4Command`` when updating the source.

887
  * `CTest Script`_ variable: :variable:`CTEST_P4_UPDATE_OPTIONS`
888
889
890
891
892
  * :module:`CTest` module variable: ``CTEST_P4_UPDATE_OPTIONS``

``SVNCommand``
  ``svn`` command-line tool to use if source tree is managed by Subversion.

893
  * `CTest Script`_ variable: :variable:`CTEST_SVN_COMMAND`
894
895
896
897
898
  * :module:`CTest` module variable: ``SVNCOMMAND``

``SVNOptions``
  Command-line options to the ``SVNCommand`` for all invocations.

899
  * `CTest Script`_ variable: :variable:`CTEST_SVN_OPTIONS`
900
901
902
903
904
  * :module:`CTest` module variable: ``CTEST_SVN_OPTIONS``

``SVNUpdateOptions``
  Command-line options to the ``SVNCommand`` when updating the source.

905
  * `CTest Script`_ variable: :variable:`CTEST_SVN_UPDATE_OPTIONS`
906
907
908
909
910
911
  * :module:`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.

912
  * `CTest Script`_ variable: :variable:`CTEST_UPDATE_COMMAND`
913
914
915
916
917
918
  * :module:`CTest` module variable: ``<VCS>COMMAND``
    when ``UPDATE_TYPE`` is ``<vcs>``, else ``UPDATE_COMMAND``

``UpdateOptions``
  Command-line options to the ``UpdateCommand``.

919
  * `CTest Script`_ variable: :variable:`CTEST_UPDATE_OPTIONS`
920
921
922
923
924
925
926
927
928
929
930
931
932
  * :module:`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
  * :module:`CTest` module variable: ``UPDATE_TYPE`` if set,
    else ``CTEST_UPDATE_TYPE``

933
934
.. _`UpdateVersionOnly`:

935
936
937
938
939
940
941
``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: :variable:`CTEST_UPDATE_VERSION_ONLY`

942
943
944
945
946
947
948
949
950
951
952
953
.. _`UpdateVersionOverride`:

``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: :variable:`CTEST_UPDATE_VERSION_OVERRIDE`
954

955
956
957
958
959
960
961
962
963
964
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.

965
  * `CTest Script`_ variable: :variable:`CTEST_NIGHTLY_START_TIME`
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
  * :module:`CTest` module variable: ``NIGHTLY_START_TIME`` if set,
    else ``CTEST_NIGHTLY_START_TIME``

.. _`CTest Configure Step`:

CTest Configure Step
--------------------

In a `CTest Script`_, the :command:`ctest_configure` command runs this step.
Arguments to the command may specify some of the step settings.

Configuration settings include:

``ConfigureCommand``
  Command-line to launch the software configuration process.
  It will be executed in the location specified by the
  ``BuildDirectory`` setting.

984
  * `CTest Script`_ variable: :variable:`CTEST_CONFIGURE_COMMAND`
985
986
987
  * :module:`CTest` module variable: :variable:`CMAKE_COMMAND`
    followed by :variable:`PROJECT_SOURCE_DIR`

988
989
990
991
992
993
994
995
``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: :variable:`CTEST_LABELS_FOR_SUBPROJECTS`
  * :module:`CTest` module variable: ``CTEST_LABELS_FOR_SUBPROJECTS``

996
  See `Label and Subproject Summary`_.
997

998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
.. _`CTest Build Step`:

CTest Build Step
----------------

In a `CTest Script`_, the :command:`ctest_build` command runs this step.
Arguments to the command may specify some of the step settings.

Configuration settings include:

``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.

1016
  * `CTest Script`_ variable: :variable:`CTEST_CONFIGURATION_TYPE`
1017
  * :module:`CTest` module variable: ``DEFAULT_CTEST_CONFIGURATION_TYPE``,
1018
    initialized by the :envvar:`CMAKE_CONFIG_TYPE` environment variable
1019

1020
1021
1022
1023
1024
1025
1026
1027
``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: :variable:`CTEST_LABELS_FOR_SUBPROJECTS`
  * :module:`CTest` module variable: ``CTEST_LABELS_FOR_SUBPROJECTS``

1028
1029
  See `Label and Subproject Summary`_.

1030
1031
1032
1033
1034
``MakeCommand``
  Command-line to launch the software build process.
  It will be executed in the location specified by the
  ``BuildDirectory`` setting.

1035
  * `CTest Script`_ variable: :variable:`CTEST_BUILD_COMMAND`
1036
1037
1038
1039
  * :module:`CTest` module variable: ``MAKECOMMAND``,
    initialized by the :command:`build_command` command

``UseLaunchers``
1040
1041
1042
  For build trees generated by CMake using one of the
  :ref:`Makefile Generators` or the :generator:`Ninja`
  generator, specify whether the
1043
1044
1045
1046
1047
1048
1049
1050
1051
  ``CTEST_USE_LAUNCHERS`` feature is enabled by the
  :module:`CTestUseLaunchers` module (also included by the
  :module:`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.

1052
  * `CTest Script`_ variable: :variable:`CTEST_USE_LAUNCHERS`
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
  * :module:`CTest` module variable: ``CTEST_USE_LAUNCHERS``

.. _`CTest Test Step`:

CTest Test Step
---------------

In a `CTest Script`_, the :command:`ctest_test` command runs this step.
Arguments to the command may specify some of the step settings.

Configuration settings include:

1065
``ResourceSpecFile``
1066
  Specify a
1067
1068
1069
1070
1071
1072
  :ref:`resource specification file <ctest-resource-specification-file>`.

  * `CTest Script`_ variable: :variable:`CTEST_RESOURCE_SPEC_FILE`
  * :module:`CTest` module variable: ``CTEST_RESOURCE_SPEC_FILE``

  See :ref:`ctest-resource-allocation` for more information.
1073

1074
1075
1076
1077
1078
1079
1080
1081
``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: :variable:`CTEST_LABELS_FOR_SUBPROJECTS`
  * :module:`CTest` module variable: ``CTEST_LABELS_FOR_SUBPROJECTS``

1082
  See `Label and Subproject Summary`_.
1083

1084
1085
1086
1087
1088
1089
1090
``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: :variable:`CTEST_TEST_LOAD`
  * :module:`CTest` module variable: ``CTEST_TEST_LOAD``

1091
1092
1093
1094
``TimeOut``
  The default timeout for each test if not specified by the
  :prop_test:`TIMEOUT` test property.

1095
  * `CTest Script`_ variable: :variable:`CTEST_TEST_TIMEOUT`
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
  * :module:`CTest` module variable: ``DART_TESTING_TIMEOUT``

.. _`CTest Coverage Step`:

CTest Coverage Step
-------------------

In a `CTest Script`_, the :command:`ctest_coverage` command runs this step.
Arguments to the command may specify some of the step settings.

Configuration settings include:

``CoverageCommand``
  Command-line tool to perform software coverage analysis.
  It will be executed in the location specified by the
  ``BuildDirectory`` setting.

1113
  * `CTest Script`_ variable: :variable:`CTEST_COVERAGE_COMMAND`
1114
1115
1116