diff options
Diffstat (limited to 'Help/command')
| -rw-r--r-- | Help/command/cmake_host_system_information.rst | 41 | ||||
| -rw-r--r-- | Help/command/configure_file.rst | 14 | ||||
| -rw-r--r-- | Help/command/execute_process.rst | 9 | ||||
| -rw-r--r-- | Help/command/file.rst | 13 | ||||
| -rw-r--r-- | Help/command/include_guard.rst | 46 |
5 files changed, 107 insertions, 16 deletions
diff --git a/Help/command/cmake_host_system_information.rst b/Help/command/cmake_host_system_information.rst index 9402d57..7199874 100644 --- a/Help/command/cmake_host_system_information.rst +++ b/Help/command/cmake_host_system_information.rst @@ -13,13 +13,34 @@ queried. The list of queried values is stored in ``<variable>``. ``<key>`` can be one of the following values: -:: - - NUMBER_OF_LOGICAL_CORES = Number of logical cores. - NUMBER_OF_PHYSICAL_CORES = Number of physical cores. - HOSTNAME = Hostname. - FQDN = Fully qualified domain name. - TOTAL_VIRTUAL_MEMORY = Total virtual memory in megabytes. - AVAILABLE_VIRTUAL_MEMORY = Available virtual memory in megabytes. - TOTAL_PHYSICAL_MEMORY = Total physical memory in megabytes. - AVAILABLE_PHYSICAL_MEMORY = Available physical memory in megabytes. +============================= ================================================ +Key Description +============================= ================================================ +``NUMBER_OF_LOGICAL_CORES`` Number of logical cores +``NUMBER_OF_PHYSICAL_CORES`` Number of physical cores +``HOSTNAME`` Hostname +``FQDN`` Fully qualified domain name +``TOTAL_VIRTUAL_MEMORY`` Total virtual memory in megabytes +``AVAILABLE_VIRTUAL_MEMORY`` Available virtual memory in megabytes +``TOTAL_PHYSICAL_MEMORY`` Total physical memory in megabytes +``AVAILABLE_PHYSICAL_MEMORY`` Available physical memory in megabytes +``IS_64BIT`` One if processor is 64Bit +``HAS_FPU`` One if processor has floating point unit +``HAS_MMX`` One if processor supports MMX instructions +``HAS_MMX_PLUS`` One if porcessor supports Ext. MMX instructions +``HAS_SSE`` One if porcessor supports SSE instructions +``HAS_SSE2`` One if porcessor supports SSE2 instructions +``HAS_SSE_FP`` One if porcessor supports SSE FP instructions +``HAS_SSE_MMX`` One if porcessor supports SSE MMX instructions +``HAS_AMD_3DNOW`` One if porcessor supports 3DNow instructions +``HAS_AMD_3DNOW_PLUS`` One if porcessor supports 3DNow+ instructions +``HAS_IA64`` One if IA64 processor emulating x86 +``HAS_SERIAL_NUMBER`` One if processor has serial number +``PROCESSOR_SERIAL_NUMBER`` Processor serial number +``PROCESSOR_NAME`` Human readable processor name +``PROCESSOR_DESCRIPTION`` Human readable full processor description +``OS_NAME`` See :variable:`CMAKE_HOST_SYSTEM_NAME` +``OS_RELEASE`` The OS sub-type e.g. on Windows ``Professional`` +``OS_VERSION`` The OS build ID +``OS_PLATFORM`` See :variable:`CMAKE_HOST_SYSTEM_PROCESSOR` +============================= ================================================ diff --git a/Help/command/configure_file.rst b/Help/command/configure_file.rst index 4304f09..e08c573 100644 --- a/Help/command/configure_file.rst +++ b/Help/command/configure_file.rst @@ -30,9 +30,23 @@ a false constant by the :command:`if` command. The "..." content on the line after the variable name, if any, is processed as above. Input file lines of the form ``#cmakedefine01 VAR`` will be replaced with either ``#define VAR 1`` or ``#define VAR 0`` similarly. +The result lines (with the exception of the ``#undef`` comments) can be +indented using spaces and/or tabs between the ``#`` character +and the ``cmakedefine`` or ``cmakedefine01`` words. This whitespace +indentation will be preserved in the output lines:: + + # cmakedefine VAR + # cmakedefine01 VAR + +will be replaced, if ``VAR`` is defined, with:: + + # define VAR + # define VAR 1 If the input file is modified the build system will re-run CMake to re-configure the file and generate the build system again. +The generated file is modified and its timestamp updated on subsequent +cmake runs only if its content is changed. The arguments are: diff --git a/Help/command/execute_process.rst b/Help/command/execute_process.rst index d617243..799493f 100644 --- a/Help/command/execute_process.rst +++ b/Help/command/execute_process.rst @@ -10,6 +10,7 @@ Execute one or more child processes. [WORKING_DIRECTORY <directory>] [TIMEOUT <seconds>] [RESULT_VARIABLE <variable>] + [RESULTS_VARIABLE <variable>] [OUTPUT_VARIABLE <variable>] [ERROR_VARIABLE <variable>] [INPUT_FILE <file>] @@ -49,10 +50,16 @@ Options: specified number of seconds (fractions are allowed). ``RESULT_VARIABLE`` - The variable will be set to contain the result of running the processes. + The variable will be set to contain the result of last child process. This will be an integer return code from the last child or a string describing an error condition. +``RESULTS_VARIABLE <variable>`` + The variable will be set to contain the result of all processes as a + :ref:`;-list <CMake Language Lists>`, in order of the given ``COMMAND`` + arguments. Each entry will be an integer return code from the + corresponding child or a string describing an error condition. + ``OUTPUT_VARIABLE``, ``ERROR_VARIABLE`` The variable named will be set with the contents of the standard output and standard error pipes, respectively. If the same variable is named diff --git a/Help/command/file.rst b/Help/command/file.rst index e7a5d50..edccac5 100644 --- a/Help/command/file.rst +++ b/Help/command/file.rst @@ -108,9 +108,7 @@ Generate a list of files that match the ``<globbing-expressions>`` and store it into the ``<variable>``. Globbing expressions are similar to regular expressions, but much simpler. If ``RELATIVE`` flag is specified, the results will be returned as relative paths to the given -path. No specific order of results is defined other than that it is -deterministic. If order is important then sort the list explicitly -(e.g. using the :command:`list(SORT)` command). +path. The results will be ordered lexicographically. By default ``GLOB`` lists directories - directories are omited in result if ``LIST_DIRECTORIES`` is set to false. @@ -294,6 +292,8 @@ from the input content to produce the output content. The options are: ``INPUT <input-file>`` Use the content from a given file as input. + A relative path is treated with respect to the value of + :variable:`CMAKE_CURRENT_SOURCE_DIR`. See policy :policy:`CMP0070`. ``OUTPUT <output-file>`` Specify the output file name to generate. Use generator expressions @@ -301,11 +301,14 @@ from the input content to produce the output content. The options are: name. Multiple configurations may generate the same output file only if the generated content is identical. Otherwise, the ``<output-file>`` must evaluate to an unique name for each configuration. + A relative path (after evaluating generator expressions) is treated + with respect to the value of :variable:`CMAKE_CURRENT_BINARY_DIR`. + See policy :policy:`CMP0070`. Exactly one ``CONTENT`` or ``INPUT`` option must be given. A specific ``OUTPUT`` file may be named by at most one invocation of ``file(GENERATE)``. -Generated files are modified on subsequent cmake runs only if their content -is changed. +Generated files are modified and their timestamp updated on subsequent cmake +runs only if their content is changed. Note also that ``file(GENERATE)`` does not create the output file until the generation phase. The output file will not yet have been written when the diff --git a/Help/command/include_guard.rst b/Help/command/include_guard.rst new file mode 100644 index 0000000..62cce22 --- /dev/null +++ b/Help/command/include_guard.rst @@ -0,0 +1,46 @@ +include_guard +------------- + +Provides an include guard for the file currently being processed by CMake. + +:: + + include_guard([DIRECTORY|GLOBAL]) + +Sets up an include guard for the current CMake file (see the +:variable:`CMAKE_CURRENT_LIST_FILE` variable documentation). + +CMake will end its processing of the current file at the location of the +:command:`include_guard` command if the current file has already been +processed for the applicable scope (see below). This provides functionality +similar to the include guards commonly used in source headers or to the +``#pragma once`` directive. If the current file has been processed previously +for the applicable scope, the effect is as though :command:`return` had been +called. Do not call this command from inside a function being defined within +the current file. + +An optional argument specifying the scope of the guard may be provided. +Possible values for the option are: + +``DIRECTORY`` + The include guard applies within the current directory and below. The file + will only be included once within this directory scope, but may be included + again by other files outside of this directory (i.e. a parent directory or + another directory not pulled in by :command:`add_subdirectory` or + :command:`include` from the current file or its children). + +``GLOBAL`` + The include guard applies globally to the whole build. The current file + will only be included once regardless of the scope. + +If no arguments given, ``include_guard`` has the same scope as a variable, +meaning that the include guard effect is isolated by the most recent +function scope or current directory if no inner function scopes exist. +In this case the command behavior is the same as: + +.. code-block:: cmake + + if(__CURRENT_FILE_VAR__) + return() + endif() + set(__CURRENT_FILE_VAR__ TRUE) |