Felix Geyer
8 years ago
parent
dc0a468c31
commit
b8500fbc10
@ -0,0 +1,7 @@
|
||||
# Exclude MacOS Finder files.
|
||||
.DS_Store
|
||||
|
||||
*.user*
|
||||
|
||||
*.pyc
|
||||
Testing
|
||||
@ -1,4 +1,4 @@
|
||||
install(FILES cmake-help.vim cmake-indent.vim cmake-syntax.vim DESTINATION ${CMAKE_DATA_DIR}/editors/vim)
|
||||
install(DIRECTORY vim/indent vim/syntax DESTINATION ${CMAKE_DATA_DIR}/editors/vim)
|
||||
install(FILES cmake-mode.el DESTINATION ${CMAKE_DATA_DIR}/editors/emacs)
|
||||
install(FILES cmake.m4 DESTINATION share/aclocal)
|
||||
add_subdirectory (bash-completion)
|
||||
|
||||
@ -1,21 +0,0 @@
|
||||
nmap ,hc :call OpenCmakeHelp()<CR>
|
||||
|
||||
function! OpenCmakeHelp()
|
||||
let s = getline( '.' )
|
||||
let i = col( '.' ) - 1
|
||||
while i > 0 && strpart( s, i, 1 ) =~ '[A-Za-z0-9_]'
|
||||
let i = i - 1
|
||||
endwhile
|
||||
while i < col('$') && strpart( s, i, 1 ) !~ '[A-Za-z0-9_]'
|
||||
let i = i + 1
|
||||
endwhile
|
||||
let start = match( s, '[A-Za-z0-9_]\+', i )
|
||||
let end = matchend( s, '[A-Za-z0-9_]\+', i )
|
||||
let ident = strpart( s, start, end - start )
|
||||
execute "vertical new"
|
||||
execute "%!cmake --help-command ".ident
|
||||
set nomodified
|
||||
set readonly
|
||||
endfunction
|
||||
|
||||
autocmd BufRead,BufNewFile *.cmake,CMakeLists.txt,*.cmake.in nmap <F1> :call OpenCmakeHelp()<CR>
|
||||
@ -1,89 +0,0 @@
|
||||
" =============================================================================
|
||||
"
|
||||
" Program: CMake - Cross-Platform Makefile Generator
|
||||
" Module: $RCSfile$
|
||||
" Language: VIM
|
||||
" Date: $Date$
|
||||
" Version: $Revision$
|
||||
"
|
||||
" =============================================================================
|
||||
|
||||
" Vim syntax file
|
||||
" Language: CMake
|
||||
" Author: Andy Cedilnik <andy.cedilnik@kitware.com>
|
||||
" Maintainer: Karthik Krishnan <karthik.krishnan@kitware.com>
|
||||
" Last Change: $Date$
|
||||
" Version: $Revision$
|
||||
"
|
||||
" Licence: The CMake license applies to this file. See
|
||||
" https://cmake.org/licensing
|
||||
" This implies that distribution with Vim is allowed
|
||||
|
||||
" For version 5.x: Clear all syntax items
|
||||
" For version 6.x: Quit when a syntax file was already loaded
|
||||
if version < 600
|
||||
syntax clear
|
||||
elseif exists("b:current_syntax")
|
||||
finish
|
||||
endif
|
||||
|
||||
syn case ignore
|
||||
syn match cmakeEscaped /\(\\\\\|\\"\|\\n\|\\t\)/ contained
|
||||
syn region cmakeComment start="#" end="$" contains=cmakeTodo
|
||||
syn region cmakeRegistry start=/\[/ end=/]/
|
||||
\ contained oneline contains=CONTAINED,cmakeTodo,cmakeEscaped
|
||||
syn region cmakeVariableValue start=/\${/ end=/}/
|
||||
\ contained oneline contains=CONTAINED,cmakeTodo
|
||||
syn region cmakeEnvironment start=/\$ENV{/ end=/}/
|
||||
\ contained oneline contains=CONTAINED,cmakeTodo
|
||||
syn region cmakeString start=/"/ end=/"/
|
||||
\ contains=CONTAINED,cmakeTodo,cmakeOperators
|
||||
syn region cmakeArguments start=/(/ end=/)/
|
||||
\ contains=ALLBUT,cmakeArguments,cmakeTodo
|
||||
syn keyword cmakeSystemVariables
|
||||
\ WIN32 UNIX APPLE CYGWIN BORLAND MINGW MSVC MSVC_IDE MSVC60 MSVC70 MSVC71 MSVC80 MSVC90
|
||||
syn keyword cmakeOperators
|
||||
\ ABSOLUTE AND BOOL CACHE COMMAND DEFINED DOC EQUAL EXISTS EXT FALSE GREATER INTERNAL LESS MATCHES NAME NAMES NAME_WE NOT OFF ON OR PATH PATHS PROGRAM STREQUAL STRGREATER STRING STRLESS TRUE
|
||||
\ contained
|
||||
syn keyword cmakeDeprecated ABSTRACT_FILES BUILD_NAME SOURCE_FILES SOURCE_FILES_REMOVE VTK_MAKE_INSTANTIATOR VTK_WRAP_JAVA VTK_WRAP_PYTHON VTK_WRAP_TCL WRAP_EXCLUDE_FILES
|
||||
\ nextgroup=cmakeArguments
|
||||
|
||||
" The keywords are generated as: cmake --help-command-list | tr "\n" " " | tr "[:lower:]" "[:upper:]"
|
||||
syn keyword cmakeStatement
|
||||
\ ADD_COMPILE_OPTIONS ADD_CUSTOM_COMMAND ADD_CUSTOM_TARGET ADD_DEFINITIONS ADD_DEPENDENCIES ADD_EXECUTABLE ADD_LIBRARY ADD_SUBDIRECTORY ADD_TEST AUX_SOURCE_DIRECTORY BREAK BUILD_COMMAND BUILD_NAME CMAKE_HOST_SYSTEM_INFORMATION CMAKE_MINIMUM_REQUIRED CMAKE_POLICY CONFIGURE_FILE CREATE_TEST_SOURCELIST CTEST_BUILD CTEST_CONFIGURE CTEST_COVERAGE CTEST_EMPTY_BINARY_DIRECTORY CTEST_MEMCHECK CTEST_READ_CUSTOM_FILES CTEST_RUN_SCRIPT CTEST_SLEEP CTEST_START CTEST_SUBMIT CTEST_TEST CTEST_UPDATE CTEST_UPLOAD DEFINE_PROPERTY ELSE ELSEIF ENABLE_LANGUAGE ENABLE_TESTING ENDFOREACH ENDFUNCTION ENDIF ENDMACRO ENDWHILE EXEC_PROGRAM EXECUTE_PROCESS EXPORT EXPORT_LIBRARY_DEPENDENCIES FILE FIND_FILE FIND_LIBRARY FIND_PACKAGE FIND_PATH FIND_PROGRAM FLTK_WRAP_UI FOREACH FUNCTION GET_CMAKE_PROPERTY GET_DIRECTORY_PROPERTY GET_FILENAME_COMPONENT GET_PROPERTY GET_SOURCE_FILE_PROPERTY GET_TARGET_PROPERTY GET_TEST_PROPERTY IF INCLUDE INCLUDE_DIRECTORIES INCLUDE_EXTERNAL_MSPROJECT INCLUDE_REGULAR_EXPRESSION INSTALL INSTALL_FILES INSTALL_PROGRAMS INSTALL_TARGETS LINK_DIRECTORIES LINK_LIBRARIES LIST LOAD_CACHE LOAD_COMMAND MACRO MAKE_DIRECTORY MARK_AS_ADVANCED MATH MESSAGE OPTION OUTPUT_REQUIRED_FILES PROJECT QT_WRAP_CPP QT_WRAP_UI REMOVE REMOVE_DEFINITIONS RETURN SEPARATE_ARGUMENTS SET SET_DIRECTORY_PROPERTIES SET_PROPERTY SET_SOURCE_FILES_PROPERTIES SET_TARGET_PROPERTIES SET_TESTS_PROPERTIES SITE_NAME SOURCE_GROUP STRING SUBDIR_DEPENDS SUBDIRS TARGET_COMPILE_DEFINITIONS TARGET_COMPILE_FEATURES TARGET_COMPILE_OPTIONS TARGET_INCLUDE_DIRECTORIES TARGET_LINK_LIBRARIES TARGET_SOURCES TRY_COMPILE TRY_RUN UNSET USE_MANGLED_MESA UTILITY_SOURCE VARIABLE_REQUIRES VARIABLE_WATCH WHILE WRITE_FILE
|
||||
\ nextgroup=cmakeArguments
|
||||
syn keyword cmakeTodo
|
||||
\ TODO FIXME XXX
|
||||
\ contained
|
||||
|
||||
" Define the default highlighting.
|
||||
" For version 5.7 and earlier: only when not done already
|
||||
" For version 5.8 and later: only when an item doesn't have highlighting yet
|
||||
if version >= 508 || !exists("did_cmake_syntax_inits")
|
||||
if version < 508
|
||||
let did_cmake_syntax_inits = 1
|
||||
command -nargs=+ HiLink hi link <args>
|
||||
else
|
||||
command -nargs=+ HiLink hi def link <args>
|
||||
endif
|
||||
|
||||
HiLink cmakeStatement Statement
|
||||
HiLink cmakeComment Comment
|
||||
HiLink cmakeString String
|
||||
HiLink cmakeVariableValue Type
|
||||
HiLink cmakeRegistry Underlined
|
||||
HiLink cmakeArguments Identifier
|
||||
HiLink cmakeArgument Constant
|
||||
HiLink cmakeEnvironment Special
|
||||
HiLink cmakeOperators Operator
|
||||
HiLink cmakeMacro PreProc
|
||||
HiLink cmakeError Error
|
||||
HiLink cmakeTodo TODO
|
||||
HiLink cmakeEscaped Special
|
||||
|
||||
delcommand HiLink
|
||||
endif
|
||||
|
||||
let b:current_syntax = "cmake"
|
||||
|
||||
"EOF"
|
||||
File diff suppressed because one or more lines are too long
@ -0,0 +1,141 @@
|
||||
#!/usr/bin/env perl
|
||||
|
||||
use strict;
|
||||
use warnings;
|
||||
|
||||
my @variables;
|
||||
my @commands;
|
||||
my @properties;
|
||||
my @modules;
|
||||
my %keywords; # command => keyword-list
|
||||
|
||||
# unwanted upper-cases
|
||||
my %unwanted = map { $_ => 1 } qw(VS CXX IDE NOTFOUND NO_ DFOO DBAR);
|
||||
# cannot remove ALL - exists for add_custom_command
|
||||
|
||||
# control-statements
|
||||
my %conditional = map { $_ => 1 } qw(if else elseif endif);
|
||||
my %loop = map { $_ => 1 } qw(foreach while endforeach endwhile);
|
||||
|
||||
# decrecated
|
||||
my %deprecated = map { $_ => 1 } qw(build_name exec_program export_library_dependencies install_files install_programs install_targets link_libraries make_directory output_required_files remove subdir_depends subdirs use_mangled_mesa utility_source variable_requires write_file);
|
||||
|
||||
# add some (popular) modules
|
||||
push @modules, "ExternalProject";
|
||||
|
||||
# variables
|
||||
open(CMAKE, "cmake --help-variable-list|") or die "could not run cmake";
|
||||
while (<CMAKE>) {
|
||||
chomp;
|
||||
push @variables, $_;
|
||||
}
|
||||
close(CMAKE);
|
||||
|
||||
# transform all variables in a hash - to be able to use exists later on
|
||||
my %variables = map { $_ => 1 } @variables;
|
||||
|
||||
# commands
|
||||
open(CMAKE, "cmake --help-command-list|");
|
||||
while (my $cmd = <CMAKE>) {
|
||||
chomp $cmd;
|
||||
|
||||
push @commands, $cmd;
|
||||
}
|
||||
close(CMAKE);
|
||||
|
||||
# now generate a keyword-list per command
|
||||
foreach my $cmd (@commands) {
|
||||
my @word = extract_upper("cmake --help-command $cmd|");
|
||||
|
||||
next if scalar @word == 0;
|
||||
|
||||
$keywords{$cmd} = [ sort keys %{ { map { $_ => 1 } @word } } ];
|
||||
}
|
||||
|
||||
# and now for modules
|
||||
foreach my $mod (@modules) {
|
||||
my @word = extract_upper("cmake --help-module $mod|");
|
||||
|
||||
next if scalar @word == 0;
|
||||
|
||||
$keywords{$mod} = [ sort keys %{ { map { $_ => 1 } @word } } ];
|
||||
}
|
||||
|
||||
# and now for generator-expressions
|
||||
my @generator_expr = extract_upper("cmake --help-manual cmake-generator-expressions |");
|
||||
|
||||
# properties
|
||||
open(CMAKE, "cmake --help-property-list|");
|
||||
while (<CMAKE>) {
|
||||
chomp;
|
||||
push @properties, $_;
|
||||
}
|
||||
close(CMAKE);
|
||||
|
||||
# generate cmake.vim
|
||||
open(IN, "<cmake.vim.in") or die "could not read cmake.vim.in";
|
||||
open(OUT, ">syntax/cmake.vim") or die "could not write to syntax/cmake.vim";
|
||||
|
||||
my @keyword_hi;
|
||||
|
||||
while(<IN>)
|
||||
{
|
||||
if (m/\@([A-Z0-9_]+)\@/) { # match for @SOMETHING@
|
||||
if ($1 eq "COMMAND_LIST") {
|
||||
# do not include "special" commands in this list
|
||||
my @tmp = grep { ! exists $conditional{$_} and
|
||||
! exists $loop{$_} and
|
||||
! exists $deprecated{$_} } @commands;
|
||||
print OUT " " x 12 , "\\ ", join(" ", @tmp), "\n";
|
||||
} elsif ($1 eq "VARIABLE_LIST") {
|
||||
print OUT " " x 12 , "\\ ", join(" ", @variables), "\n";
|
||||
} elsif ($1 eq "MODULES") {
|
||||
print OUT " " x 12 , "\\ ", join("\n", @modules), "\n";
|
||||
} elsif ($1 eq "GENERATOR_EXPRESSIONS") {
|
||||
print OUT " " x 12 , "\\ ", join(" ", @generator_expr), "\n";
|
||||
} elsif ($1 eq "CONDITIONALS") {
|
||||
print OUT " " x 12 , "\\ ", join(" ", sort keys %conditional), "\n";
|
||||
} elsif ($1 eq "LOOPS") {
|
||||
print OUT " " x 12 , "\\ ", join(" ", sort keys %loop), "\n";
|
||||
} elsif ($1 eq "DEPRECATED") {
|
||||
print OUT " " x 12 , "\\ ", join(" ", sort keys %deprecated), "\n";
|
||||
} elsif ($1 eq "KEYWORDS") {
|
||||
foreach my $k (sort keys %keywords) {
|
||||
print OUT "syn keyword cmakeKW$k\n";
|
||||
print OUT " " x 12, "\\ ", join(" ", @{$keywords{$k}}), "\n";
|
||||
print OUT " " x 12, "\\ contained\n";
|
||||
print OUT "\n";
|
||||
push @keyword_hi, "hi def link cmakeKW$k ModeMsg";
|
||||
}
|
||||
} elsif ($1 eq "KEYWORDS_HIGHLIGHT") {
|
||||
print OUT join("\n", @keyword_hi), "\n";
|
||||
} else {
|
||||
print "ERROR do not know how to replace $1\n";
|
||||
}
|
||||
} else {
|
||||
print OUT $_;
|
||||
}
|
||||
}
|
||||
close(IN);
|
||||
close(OUT);
|
||||
|
||||
sub extract_upper
|
||||
{
|
||||
my $input = shift;
|
||||
my @word;
|
||||
|
||||
open(KW, $input);
|
||||
while (<KW>) {
|
||||
|
||||
foreach my $w (m/\b([A-Z_]{2,})\b/g) {
|
||||
next
|
||||
if exists $variables{$w} or # skip if it is a variable
|
||||
exists $unwanted{$w}; # skip if not wanted
|
||||
|
||||
push @word, $w;
|
||||
}
|
||||
}
|
||||
close(KW);
|
||||
|
||||
return @word;
|
||||
}
|
||||
@ -1,13 +1,3 @@
|
||||
" =============================================================================
|
||||
"
|
||||
" Program: CMake - Cross-Platform Makefile Generator
|
||||
" Module: $RCSfile$
|
||||
" Language: VIM
|
||||
" Date: $Date$
|
||||
" Version: $Revision$
|
||||
"
|
||||
" =============================================================================
|
||||
|
||||
" Vim indent file
|
||||
" Language: CMake (ft=cmake)
|
||||
" Author: Andy Cedilnik <andy.cedilnik@kitware.com>
|
||||
File diff suppressed because one or more lines are too long
@ -1,15 +1,20 @@
|
||||
get_cmake_property
|
||||
------------------
|
||||
|
||||
Get a property of the CMake instance.
|
||||
Get a global property of the CMake instance.
|
||||
|
||||
::
|
||||
|
||||
get_cmake_property(VAR property)
|
||||
|
||||
Get a property from the CMake instance. The value of the property is
|
||||
Get a global property from the CMake instance. The value of the property is
|
||||
stored in the variable ``VAR``. If the property is not found, ``VAR``
|
||||
will be set to "NOTFOUND". See the :manual:`cmake-properties(7)` manual
|
||||
for available properties.
|
||||
|
||||
See also the more general :command:`get_property` command.
|
||||
See also the :command:`get_property` command ``GLOBAL`` option.
|
||||
|
||||
In addition to global properties, this command (for historical reasons)
|
||||
also supports the :prop_dir:`VARIABLES` and :prop_dir:`MACROS` directory
|
||||
properties. It also supports a special ``COMPONENTS`` global property that
|
||||
lists the components given to the :command:`install` command.
|
||||
|
||||
@ -0,0 +1,16 @@
|
||||
Visual Studio 15
|
||||
----------------
|
||||
|
||||
Generates Visual Studio 15 project files.
|
||||
|
||||
The :variable:`CMAKE_GENERATOR_PLATFORM` variable may be set
|
||||
to specify a target platform name (architecture).
|
||||
|
||||
For compatibility with CMake versions prior to 3.1, one may specify
|
||||
a target platform name optionally at the end of this generator name:
|
||||
|
||||
``Visual Studio 15 Win64``
|
||||
Specify target platform ``x64``.
|
||||
|
||||
``Visual Studio 15 ARM``
|
||||
Specify target platform ``ARM``.
|
||||
@ -0,0 +1,703 @@
|
||||
.. cmake-manual-description: CMake Server
|
||||
|
||||
cmake-server(7)
|
||||
***************
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. contents::
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
||||
:manual:`cmake(1)` is capable of providing semantic information about
|
||||
CMake code it executes to generate a buildsystem. If executed with
|
||||
the ``-E server`` command line options, it starts in a long running mode
|
||||
and allows a client to request the available information via a JSON protocol.
|
||||
|
||||
The protocol is designed to be useful to IDEs, refactoring tools, and
|
||||
other tools which have a need to understand the buildsystem in entirety.
|
||||
|
||||
A single :manual:`cmake-buildsystem(7)` may describe buildsystem contents
|
||||
and build properties which differ based on
|
||||
:manual:`generation-time context <cmake-generator-expressions(7)>`
|
||||
including:
|
||||
|
||||
* The Platform (eg, Windows, APPLE, Linux).
|
||||
* The build configuration (eg, Debug, Release, Coverage).
|
||||
* The Compiler (eg, MSVC, GCC, Clang) and compiler version.
|
||||
* The language of the source files compiled.
|
||||
* Available compile features (eg CXX variadic templates).
|
||||
* CMake policies.
|
||||
|
||||
The protocol aims to provide information to tooling to satisfy several
|
||||
needs:
|
||||
|
||||
#. Provide a complete and easily parsed source of all information relevant
|
||||
to the tooling as it relates to the source code. There should be no need
|
||||
for tooling to parse generated buildsystems to access include directories
|
||||
or compile definitions for example.
|
||||
#. Semantic information about the CMake buildsystem itself.
|
||||
#. Provide a stable interface for reading the information in the CMake cache.
|
||||
#. Information for determining when cmake needs to be re-run as a result of
|
||||
file changes.
|
||||
|
||||
|
||||
Operation
|
||||
=========
|
||||
|
||||
Start :manual:`cmake(1)` in the server command mode, supplying the path to
|
||||
the build directory to process::
|
||||
|
||||
cmake -E server (--debug|--pipe <NAMED_PIPE>)
|
||||
|
||||
The server will communicate using stdin/stdout (with the ``--debug`` parameter)
|
||||
or using a named pipe (with the ``--pipe <NAMED_PIPE>`` parameter).
|
||||
|
||||
When connecting to the server (via named pipe or by starting it in ``--debug``
|
||||
mode), the server will reply with a hello message::
|
||||
|
||||
[== CMake Server ==[
|
||||
{"supportedProtocolVersions":[{"major":1,"minor":0}],"type":"hello"}
|
||||
]== CMake Server ==]
|
||||
|
||||
Messages sent to and from the process are wrapped in magic strings::
|
||||
|
||||
[== CMake Server ==[
|
||||
{
|
||||
... some JSON message ...
|
||||
}
|
||||
]== CMake Server ==]
|
||||
|
||||
The server is now ready to accept further requests via the named pipe
|
||||
or stdin.
|
||||
|
||||
|
||||
Debugging
|
||||
=========
|
||||
|
||||
CMake server mode can be asked to provide statistics on execution times, etc.
|
||||
or to dump a copy of the response into a file. This is done passing a "debug"
|
||||
JSON object as a child of the request.
|
||||
|
||||
The debug object supports the "showStats" key, which takes a boolean and makes
|
||||
the server mode return a "zzzDebug" object with stats as part of its response.
|
||||
"dumpToFile" takes a string value and will cause the cmake server to copy
|
||||
the response into the given filename.
|
||||
|
||||
This is a response from the cmake server with "showStats" set to true::
|
||||
|
||||
[== CMake Server ==[
|
||||
{
|
||||
"cookie":"",
|
||||
"errorMessage":"Waiting for type \"handshake\".",
|
||||
"inReplyTo":"unknown",
|
||||
"type":"error",
|
||||
"zzzDebug": {
|
||||
"dumpFile":"/tmp/error.txt",
|
||||
"jsonSerialization":0.011016,
|
||||
"size":111,
|
||||
"totalTime":0.025995
|
||||
}
|
||||
}
|
||||
]== CMake Server ==]
|
||||
|
||||
The server has made a copy of this response into the file /tmp/error.txt and
|
||||
took 0.011 seconds to turn the JSON response into a string, and it took 0.025
|
||||
seconds to process the request in total. The reply has a size of 111 bytes.
|
||||
|
||||
|
||||
Protocol API
|
||||
============
|
||||
|
||||
|
||||
General Message Layout
|
||||
----------------------
|
||||
|
||||
All messages need to have a "type" value, which identifies the type of
|
||||
message that is passed back or forth. E.g. the initial message sent by the
|
||||
server is of type "hello". Messages without a type will generate an response
|
||||
of type "error".
|
||||
|
||||
All requests sent to the server may contain a "cookie" value. This value
|
||||
will he handed back unchanged in all responses triggered by the request.
|
||||
|
||||
All responses will contain a value "inReplyTo", which may be empty in
|
||||
case of parse errors, but will contain the type of the request message
|
||||
in all other cases.
|
||||
|
||||
|
||||
Type "reply"
|
||||
^^^^^^^^^^^^
|
||||
|
||||
This type is used by the server to reply to requests.
|
||||
|
||||
The message may -- depending on the type of the original request --
|
||||
contain values.
|
||||
|
||||
Example::
|
||||
|
||||
[== CMake Server ==[
|
||||
{"cookie":"zimtstern","inReplyTo":"handshake","type":"reply"}
|
||||
]== CMake Server ==]
|
||||
|
||||
|
||||
Type "error"
|
||||
^^^^^^^^^^^^
|
||||
|
||||
This type is used to return an error condition to the client. It will
|
||||
contain an "errorMessage".
|
||||
|
||||
Example::
|
||||
|
||||
[== CMake Server ==[
|
||||
{"cookie":"","errorMessage":"Protocol version not supported.","inReplyTo":"handshake","type":"error"}
|
||||
]== CMake Server ==]
|
||||
|
||||
|
||||
Type "progress"
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
When the server is busy for a long time, it is polite to send back replies of
|
||||
type "progress" to the client. These will contain a "progressMessage" with a
|
||||
string describing the action currently taking place as well as
|
||||
"progressMinimum", "progressMaximum" and "progressCurrent" with integer values
|
||||
describing the range of progess.
|
||||
|
||||
Messages of type "progress" will be followed by more "progress" messages or with
|
||||
a message of type "reply" or "error" that complete the request.
|
||||
|
||||
"progress" messages may not be emitted after the "reply" or "error" message for
|
||||
the request that triggered the responses was delivered.
|
||||
|
||||
|
||||
Type "message"
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
A message is triggered when the server processes a request and produces some
|
||||
form of output that should be displayed to the user. A Message has a "message"
|
||||
with the actual text to display as well as a "title" with a suggested dialog
|
||||
box title.
|
||||
|
||||
Example::
|
||||
|
||||
[== CMake Server ==[
|
||||
{"cookie":"","message":"Something happened.","title":"Title Text","inReplyTo":"handshake","type":"message"}
|
||||
]== CMake Server ==]
|
||||
|
||||
|
||||
Type "signal"
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
The server can send signals when it detects changes in the system state. Signals
|
||||
are of type "signal", have an empty "cookie" and "inReplyTo" field and always
|
||||
have a "name" set to show which signal was sent.
|
||||
|
||||
|
||||
Specific Signals
|
||||
----------------
|
||||
|
||||
The cmake server may sent signals with the following names:
|
||||
|
||||
"dirty" Signal
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
The "dirty" signal is sent whenever the server determines that the configuration
|
||||
of the project is no longer up-to-date. This happens when any of the files that have
|
||||
an influence on the build system is changed.
|
||||
|
||||
The "dirty" signal may look like this::
|
||||
|
||||
[== CMake Server ==[
|
||||
{
|
||||
"cookie":"",
|
||||
"inReplyTo":"",
|
||||
"name":"dirty",
|
||||
"type":"signal"}
|
||||
]== CMake Server ==]
|
||||
|
||||
|
||||
"fileChange" Signal
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The "fileChange" signal is sent whenever a watched file is changed. It contains
|
||||
the "path" that has changed and a list of "properties" with the kind of change
|
||||
that was detected. Possible changes are "change" and "rename".
|
||||
|
||||
The "fileChange" signal looks like this::
|
||||
|
||||
[== CMake Server ==[
|
||||
{
|
||||
"cookie":"",
|
||||
"inReplyTo":"",
|
||||
"name":"fileChange",
|
||||
"path":"/absolute/CMakeLists.txt",
|
||||
"properties":["change"],
|
||||
"type":"signal"}
|
||||
]== CMake Server ==]
|
||||
|
||||
|
||||
Specific Message Types
|
||||
----------------------
|
||||
|
||||
|
||||
Type "hello"
|
||||
^^^^^^^^^^^^
|
||||
|
||||
The initial message send by the cmake server on startup is of type "hello".
|
||||
This is the only message ever sent by the server that is not of type "reply",
|
||||
"progress" or "error".
|
||||
|
||||
It will contain "supportedProtocolVersions" with an array of server protocol
|
||||
versions supported by the cmake server. These are JSON objects with "major" and
|
||||
"minor" keys containing non-negative integer values.
|
||||
|
||||
Example::
|
||||
|
||||
[== CMake Server ==[
|
||||
{"supportedProtocolVersions":[{"major":0,"minor":1}],"type":"hello"}
|
||||
]== CMake Server ==]
|
||||
|
||||
|
||||
Type "handshake"
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
The first request that the client may send to the server is of type "handshake".
|
||||
|
||||
This request needs to pass one of the "supportedProtocolVersions" of the "hello"
|
||||
type response received earlier back to the server in the "protocolVersion" field.
|
||||
|
||||
Each protocol version may request additional attributes to be present.
|
||||
|
||||
Protocol version 1.0 requires the following attributes to be set:
|
||||
|
||||
* "sourceDirectory" with a path to the sources
|
||||
* "buildDirectory" with a path to the build directory
|
||||
* "generator" with the generator name
|
||||
* "extraGenerator" (optional!) with the extra generator to be used.
|
||||
|
||||
Example::
|
||||
|
||||
[== CMake Server ==[
|
||||
{"cookie":"zimtstern","type":"handshake","protocolVersion":{"major":0},
|
||||
"sourceDirectory":"/home/code/cmake", "buildDirectory":"/tmp/testbuild",
|
||||
"generator":"Ninja"}
|
||||
]== CMake Server ==]
|
||||
|
||||
which will result in a response type "reply"::
|
||||
|
||||
[== CMake Server ==[
|
||||
{"cookie":"zimtstern","inReplyTo":"handshake","type":"reply"}
|
||||
]== CMake Server ==]
|
||||
|
||||
indicating that the server is ready for action.
|
||||
|
||||
|
||||
Type "globalSettings"
|
||||
^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
This request can be sent after the initial handshake. It will return a
|
||||
JSON structure with information on cmake state.
|
||||
|
||||
Example::
|
||||
|
||||
[== CMake Server ==[
|
||||
{"type":"globalSettings"}
|
||||
]== CMake Server ==]
|
||||
|
||||
which will result in a response type "reply"::
|
||||
|
||||
[== CMake Server ==[
|
||||
{
|
||||
"buildDirectory": "/tmp/test-build",
|
||||
"capabilities": {
|
||||
"generators": [
|
||||
{
|
||||
"extraGenerators": [],
|
||||
"name": "Watcom WMake",
|
||||
"platformSupport": false,
|
||||
"toolsetSupport": false
|
||||
},
|
||||
<...>
|
||||
],
|
||||
"serverMode": false,
|
||||
"version": {
|
||||
"isDirty": false,
|
||||
"major": 3,
|
||||
"minor": 6,
|
||||
"patch": 20160830,
|
||||
"string": "3.6.20160830-gd6abad",
|
||||
"suffix": "gd6abad"
|
||||
}
|
||||
},
|
||||
"checkSystemVars": false,
|
||||
"cookie": "",
|
||||
"extraGenerator": "",
|
||||
"generator": "Ninja",
|
||||
"debugOutput": false,
|
||||
"inReplyTo": "globalSettings",
|
||||
"sourceDirectory": "/home/code/cmake",
|
||||
"trace": false,
|
||||
"traceExpand": false,
|
||||
"type": "reply",
|
||||
"warnUninitialized": false,
|
||||
"warnUnused": false,
|
||||
"warnUnusedCli": true
|
||||
}
|
||||
]== CMake Server ==]
|
||||
|
||||
|
||||
Type "setGlobalSettings"
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
This request can be sent to change the global settings attributes. Unknown
|
||||
attributes are going to be ignored. Read-only attributes reported by
|
||||
"globalSettings" are all capabilities, buildDirectory, generator,
|
||||
extraGenerator and sourceDirectory. Any attempt to set these will be ignored,
|
||||
too.
|
||||
|
||||
All other settings will be changed.
|
||||
|
||||
The server will respond with an empty reply message or an error.
|
||||
|
||||
Example::
|
||||
|
||||
[== CMake Server ==[
|
||||
{"type":"setGlobalSettings","debugOutput":true}
|
||||
]== CMake Server ==]
|
||||
|
||||
CMake will reply to this with::
|
||||
|
||||
[== CMake Server ==[
|
||||
{"inReplyTo":"setGlobalSettings","type":"reply"}
|
||||
]== CMake Server ==]
|
||||
|
||||
|
||||
Type "configure"
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
This request will configure a project for build.
|
||||
|
||||
To configure a build directory already containing cmake files, it is enough to
|
||||
set "buildDirectory" via "setGlobalSettings". To create a fresh build directory
|
||||
you also need to set "currentGenerator" and "sourceDirectory" via "setGlobalSettings"
|
||||
in addition to "buildDirectory".
|
||||
|
||||
You may a list of strings to "configure" via the "cacheArguments" key. These
|
||||
strings will be interpreted similar to command line arguments related to
|
||||
cache handling that are passed to the cmake command line client.
|
||||
|
||||
Example::
|
||||
|
||||
[== CMake Server ==[
|
||||
{"type":"configure", "cacheArguments":["-Dsomething=else"]}
|
||||
]== CMake Server ==]
|
||||
|
||||
CMake will reply like this (after reporting progress for some time)::
|
||||
|
||||
[== CMake Server ==[
|
||||
{"cookie":"","inReplyTo":"configure","type":"reply"}
|
||||
]== CMake Server ==]
|
||||
|
||||
|
||||
Type "compute"
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
This requist will generate build system files in the build directory and
|
||||
is only available after a project was successfully "configure"d.
|
||||
|
||||
Example::
|
||||
|
||||
[== CMake Server ==[
|
||||
{"type":"compute"}
|
||||
]== CMake Server ==]
|
||||
|
||||
CMake will reply (after reporting progress information)::
|
||||
|
||||
[== CMake Server ==[
|
||||
{"cookie":"","inReplyTo":"compute","type":"reply"}
|
||||
]== CMake Server ==]
|
||||
|
||||
|
||||
Type "codemodel"
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
The "codemodel" request can be used after a project was "compute"d successfully.
|
||||
|
||||
It will list the complete project structure as it is known to cmake.
|
||||
|
||||
The reply will contain a key "projects", which will contain a list of
|
||||
project objects, one for each (sub-)project defined in the cmake build system.
|
||||
|
||||
Each project object can have the following keys:
|
||||
|
||||
"name"
|
||||
contains the (sub-)projects name.
|
||||
"sourceDirectory"
|
||||
contains the current source directory
|
||||
"buildDirectory"
|
||||
contains the current build directory.
|
||||
"configurations"
|
||||
contains a list of configuration objects.
|
||||
|
||||
Configuration objects are used to destinquish between different
|
||||
configurations the build directory might have enabled. While most generators
|
||||
only support one configuration, others support several.
|
||||
|
||||
Each configuration object can have the following keys:
|
||||
|
||||
"name"
|
||||
contains the name of the configuration. The name may be empty.
|
||||
"targets"
|
||||
contains a list of target objects, one for each build target.
|
||||
|
||||
Target objects define individual build targets for a certain configuration.
|
||||
|
||||
Each target object can have the following keys:
|
||||
|
||||
"name"
|
||||
contains the name of the target.
|
||||
"type"
|
||||
defines the type of build of the target. Possible values are
|
||||
"STATIC_LIBRARY", "MODULE_LIBRARY", "SHARED_LIBRARY", "OBJECT_LIBRARY",
|
||||
"EXECUTABLE", "UTILITY" and "INTERFACE_LIBRARY".
|
||||
"fullName"
|
||||
contains the full name of the build result (incl. extensions, etc.).
|
||||
"sourceDirectory"
|
||||
contains the current source directory.
|
||||
"buildDirectory"
|
||||
contains the current build directory.
|
||||
"artifacts"
|
||||
with a list of build artifacts. The list is sorted with the most
|
||||
important artifacts first (e.g. a .DLL file is listed before a
|
||||
.PDB file on windows).
|
||||
"linkerLanguage"
|
||||
contains the language of the linker used to produce the artifact.
|
||||
"linkLibraries"
|
||||
with a list of libraries to link to. This value is encoded in the
|
||||
system's native shell format.
|
||||
"linkFlags"
|
||||
with a list of flags to pass to the linker. This value is encoded in
|
||||
the system's native shell format.
|
||||
"linkLanguageFlags"
|
||||
with the flags for a compiler using the linkerLanguage. This value is
|
||||
encoded in the system's native shell format.
|
||||
"frameworkPath"
|
||||
with the framework path (on Apple computers). This value is encoded
|
||||
in the system's native shell format.
|
||||
"linkPath"
|
||||
with the link path. This value is encoded in the system's native shell
|
||||
format.
|
||||
"sysroot"
|
||||
with the sysroot path.
|
||||
"fileGroups"
|
||||
contains the source files making up the target.
|
||||
|
||||
FileGroups are used to group sources using similar settings together.
|
||||
|
||||
Each fileGroup object may contain the following keys:
|
||||
|
||||
"language"
|
||||
contains the programming language used by all files in the group.
|
||||
"compileFlags"
|
||||
with a string containing all the flags passed to the compiler
|
||||
when building any of the files in this group. This value is encoded in
|
||||
the system's native shell format.
|
||||
"includePath"
|
||||
with a list of include paths. Each include path is an object
|
||||
containing a "path" with the actual include path and "isSystem" with a bool
|
||||
value informing whether this is a normal include or a system include. This
|
||||
value is encoded in the system's native shell format.
|
||||
"defines"
|
||||
with a list of defines in the form "SOMEVALUE" or "SOMEVALUE=42". This
|
||||
value is encoded in the system's native shell format.
|
||||
"sources"
|
||||
with a list of source files.
|
||||
|
||||
All file paths in the fileGroup are either absolute or relative to the
|
||||
sourceDirectory of the target.
|
||||
|
||||
Example::
|
||||
|
||||
[== CMake Server ==[
|
||||
{"type":"project"}
|
||||
]== CMake Server ==]
|
||||
|
||||
CMake will reply::
|
||||
|
||||
[== CMake Server ==[
|
||||
{
|
||||
"cookie":"",
|
||||
"type":"reply",
|
||||
"inReplyTo":"project",
|
||||
|
||||
"projects":
|
||||
[
|
||||
{
|
||||
"name":"CMAKE_FORM",
|
||||
"sourceDirectory":"/home/code/src/cmake/Source/CursesDialog/form"
|
||||
"buildDirectory":"/tmp/cmake-build-test/Source/CursesDialog/form",
|
||||
"configurations":
|
||||
[
|
||||
{
|
||||
"name":"",
|
||||
"targets":
|
||||
[
|
||||
{
|
||||
"artifactDirectory":"/tmp/cmake/Source/CursesDialog/form",
|
||||
"fileGroups":
|
||||
[
|
||||
{
|
||||
"compileFlags":" -std=gnu11",
|
||||
"defines":
|
||||
[
|
||||
"SOMETHING=1",
|
||||
"LIBARCHIVE_STATIC"
|
||||
],
|
||||
"includePath":
|
||||
[
|
||||
{ "path":"/tmp/cmake-build-test/Utilities" },
|
||||
{ "isSystem": true, "path":"/usr/include/something" },
|
||||
...
|
||||
]
|
||||
"language":"C",
|
||||
"sources":
|
||||
[
|
||||
"fld_arg.c",
|
||||
...
|
||||
"fty_regex.c"
|
||||
]
|
||||
}
|
||||
],
|
||||
"fullName":"libcmForm.a",
|
||||
"linkerLanguage":"C",
|
||||
"name":"cmForm",
|
||||
"type":"STATIC_LIBRARY"
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
},
|
||||
...
|
||||
]
|
||||
}
|
||||
]== CMake Server ==]
|
||||
|
||||
The output can be tailored to the specific needs via parameter passed when
|
||||
requesting "project" information.
|
||||
|
||||
You can have a "depth" key, which accepts "project", "configuration" and
|
||||
"target" as string values. These cause the output to be trimmed at the
|
||||
appropriate depth of the output tree.
|
||||
|
||||
You can also set "configurations" to an array of strings with configuration
|
||||
names to list. This will cause any configuration that is not listed to be
|
||||
trimmed from the output.
|
||||
|
||||
Generated files can be included in the listing by setting "includeGeneratedFiles"
|
||||
to "true". This setting defaults to "false", so generated files are not
|
||||
listed by default.
|
||||
|
||||
Finally you can limit the target types that are going to be listed. This is
|
||||
done by providing a list of target types as an array of strings to the
|
||||
"targetTypes" key.
|
||||
|
||||
|
||||
Type "cmakeInputs"
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The "cmakeInputs" requests will report files used by CMake as part
|
||||
of the build system itself.
|
||||
|
||||
This request is only available after a project was successfully
|
||||
"configure"d.
|
||||
|
||||
Example::
|
||||
|
||||
[== CMake Server ==[
|
||||
{"type":"cmakeInputs"}
|
||||
]== CMake Server ==]
|
||||
|
||||
CMake will reply with the following information::
|
||||
|
||||
[== CMake Server ==[
|
||||
{"buildFiles":
|
||||
[
|
||||
{"isCMake":true,"isTemporary":false,"sources":["/usr/lib/cmake/...", ... ]},
|
||||
{"isCMake":false,"isTemporary":false,"sources":["CMakeLists.txt", ...]},
|
||||
{"isCMake":false,"isTemporary":true,"sources":["/tmp/build/CMakeFiles/...", ...]}
|
||||
],
|
||||
"cmakeRootDirectory":"/usr/lib/cmake",
|
||||
"sourceDirectory":"/home/code/src/cmake",
|
||||
"cookie":"",
|
||||
"inReplyTo":"cmakeInputs",
|
||||
"type":"reply"
|
||||
}
|
||||
]== CMake Server ==]
|
||||
|
||||
All file names are either relative to the top level source directory or
|
||||
absolute.
|
||||
|
||||
The list of files which "isCMake" set to true are part of the cmake installation.
|
||||
|
||||
The list of files witch "isTemporary" set to true are part of the build directory
|
||||
and will not survive the build directory getting cleaned out.
|
||||
|
||||
|
||||
Type "cache"
|
||||
^^^^^^^^^^^^
|
||||
|
||||
The "cache" request can be used once a project is configured and will
|
||||
list the cached configuration values.
|
||||
|
||||
Example::
|
||||
|
||||
[== CMake Server ==[
|
||||
{"type":"cache"}
|
||||
]== CMake Server ==]
|
||||
|
||||
CMake will respond with the following output::
|
||||
|
||||
[== CMake Server ==[
|
||||
{
|
||||
"cookie":"","inReplyTo":"cache","type":"reply",
|
||||
"cache":
|
||||
[
|
||||
{
|
||||
"key":"SOMEVALUE",
|
||||
"properties":
|
||||
{
|
||||
"ADVANCED":"1",
|
||||
"HELPSTRING":"This is not helpful"
|
||||
}
|
||||
"type":"STRING",
|
||||
"value":"TEST"}
|
||||
]
|
||||
}
|
||||
]== CMake Server ==]
|
||||
|
||||
The output can be limited to a list of keys by passing an array of key names
|
||||
to the "keys" optional field of the "cache" request.
|
||||
|
||||
|
||||
Type "fileSystemWatchers"
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The server can watch the filesystem for changes. The "fileSystemWatchers"
|
||||
command will report on the files and directories watched.
|
||||
|
||||
Example::
|
||||
|
||||
[== CMake Server ==]
|
||||
{"type":"fileSystemWatchers"}
|
||||
[== CMake Server ==]
|
||||
|
||||
CMake will respond with the following output::
|
||||
|
||||
[== CMake Server ==]
|
||||
{
|
||||
"cookie":"","inReplyTo":"fileSystemWatchers","type":"reply",
|
||||
"watchedFiles": [ "/absolute/path" ],
|
||||
"watchedDirectories": [ "/absolute" ]
|
||||
}
|
||||
[== CMake Server ==]
|
||||
@ -0,0 +1 @@
|
||||
.. cmake-module:: ../../Modules/AndroidTestUtilities.cmake
|
||||
@ -0,0 +1 @@
|
||||
.. cmake-module:: ../../Modules/CPackProductBuild.cmake
|
||||
@ -0,0 +1 @@
|
||||
.. cmake-module:: ../../Modules/FindICU.cmake
|
||||
@ -0,0 +1 @@
|
||||
.. cmake-module:: ../../Modules/FindVulkan.cmake
|
||||
@ -0,0 +1,27 @@
|
||||
CMP0066
|
||||
-------
|
||||
|
||||
Honor per-config flags in :command:`try_compile` source-file signature.
|
||||
|
||||
The source file signature of the :command:`try_compile` command uses the value
|
||||
of the :variable:`CMAKE_<LANG>_FLAGS` variable in the test project so that the
|
||||
test compilation works as it would in the main project. However, CMake 3.6 and
|
||||
below do not also honor config-specific compiler flags such as those in the
|
||||
:variable:`CMAKE_<LANG>_FLAGS_DEBUG` variable. CMake 3.7 and above prefer to
|
||||
honor config-specific compiler flags too. This policy provides compatibility
|
||||
for projects that do not expect config-specific compiler flags to be used.
|
||||
|
||||
The ``OLD`` behavior of this policy is to ignore config-specific flag
|
||||
variables like :variable:`CMAKE_<LANG>_FLAGS_DEBUG` and only use CMake's
|
||||
built-in defaults for the current compiler and platform.
|
||||
|
||||
The ``NEW`` behavior of this policy is to honor config-specific flag
|
||||
variabldes like :variable:`CMAKE_<LANG>_FLAGS_DEBUG`.
|
||||
|
||||
This policy was introduced in CMake version 3.7. Unlike most policies,
|
||||
CMake version |release| does *not* warn by default when this policy
|
||||
is not set and simply uses OLD behavior. See documentation of the
|
||||
:variable:`CMAKE_POLICY_WARNING_CMP0066 <CMAKE_POLICY_WARNING_CMP<NNNN>>`
|
||||
variable to control the warning.
|
||||
|
||||
.. include:: DEPRECATED.txt
|
||||
@ -0,0 +1,5 @@
|
||||
BINARY_DIR
|
||||
----------
|
||||
|
||||
This read-only directory property reports absolute path to the binary
|
||||
directory corresponding to the source on which it is read.
|
||||
@ -0,0 +1,11 @@
|
||||
BUILDSYSTEM_TARGETS
|
||||
-------------------
|
||||
|
||||
This read-only directory property contains a
|
||||
:ref:`;-list <CMake Language Lists>` of buildsystem targets added in the
|
||||
directory by calls to the :command:`add_library`, :command:`add_executable`,
|
||||
and :command:`add_custom_target` commands. The list does not include any
|
||||
:ref:`Imported Targets` or :ref:`Alias Targets`, but does include
|
||||
:ref:`Interface Libraries`. Each entry in the list is the logical name
|
||||
of a target, suitable to pass to the :command:`get_property` command
|
||||
``TARGET`` option.
|
||||
@ -0,0 +1,5 @@
|
||||
SOURCE_DIR
|
||||
----------
|
||||
|
||||
This read-only directory property reports absolute path to the source
|
||||
directory on which it is read.
|
||||
@ -0,0 +1,15 @@
|
||||
SUBDIRECTORIES
|
||||
--------------
|
||||
|
||||
This read-only directory property contains a
|
||||
:ref:`;-list <CMake Language Lists>` of subdirectories processed so far by
|
||||
the :command:`add_subdirectory` or :command:`subdirs` commands. Each entry is
|
||||
the absolute path to the source directory (containing the ``CMakeLists.txt``
|
||||
file). This is suitable to pass to the :command:`get_property` command
|
||||
``DIRECTORY`` option.
|
||||
|
||||
.. note::
|
||||
|
||||
The :command:`subdirs` command does not process its arguments until
|
||||
after the calling directory is fully processed. Therefore looking
|
||||
up this property in the current directory will not see them.
|
||||
@ -0,0 +1,10 @@
|
||||
FIND_LIBRARY_USE_LIB32_PATHS
|
||||
----------------------------
|
||||
|
||||
Whether the :command:`find_library` command should automatically search
|
||||
``lib32`` directories.
|
||||
|
||||
``FIND_LIBRARY_USE_LIB32_PATHS`` is a boolean specifying whether the
|
||||
:command:`find_library` command should automatically search the ``lib32``
|
||||
variant of directories called ``lib`` in the search path when building 32-bit
|
||||
binaries.
|
||||
@ -0,0 +1,5 @@
|
||||
VS_TOOL_OVERRIDE
|
||||
----------------
|
||||
|
||||
Override the default Visual Studio tool that will be applied to the source file
|
||||
with a new tool not based on the extension of the file.
|
||||
@ -0,0 +1,11 @@
|
||||
XCODE_FILE_ATTRIBUTES
|
||||
---------------------
|
||||
|
||||
Add values to the Xcode ``ATTRIBUTES`` setting on its reference to a
|
||||
source file. Among other things, this can be used to set the role on
|
||||
a mig file::
|
||||
|
||||
set_source_files_properties(defs.mig
|
||||
PROPERTIES
|
||||
XCODE_FILE_ATTRIBUTES "Client;Server"
|
||||
)
|
||||
@ -0,0 +1,46 @@
|
||||
FIXTURES_CLEANUP
|
||||
----------------
|
||||
|
||||
Specifies a list of fixtures for which the test is to be treated as a cleanup
|
||||
test.
|
||||
|
||||
Fixture cleanup tests are ordinary tests with all of the usual test
|
||||
functionality. Setting the ``FIXTURES_CLEANUP`` property for a test has two
|
||||
primary effects:
|
||||
|
||||
- CTest will ensure the test executes after all other tests which list any of
|
||||
the fixtures in its :prop_test:`FIXTURES_REQUIRED` property.
|
||||
|
||||
- If CTest is asked to run only a subset of tests (e.g. using regular
|
||||
expressions or the ``--rerun-failed`` option) and the cleanup test is not in
|
||||
the set of tests to run, it will automatically be added if any tests in the
|
||||
set require any fixture listed in ``FIXTURES_CLEANUP``.
|
||||
|
||||
A cleanup test can have multiple fixtures listed in its ``FIXTURES_CLEANUP``
|
||||
property. It will execute only once for the whole CTest run, not once for each
|
||||
fixture. A fixture can also have more than one cleanup test defined. If there
|
||||
are multiple cleanup tests for a fixture, projects can control their order with
|
||||
the usual :prop_test:`DEPENDS` test property if necessary.
|
||||
|
||||
A cleanup test is allowed to require other fixtures, but not any fixture listed
|
||||
in its ``FIXTURES_CLEANUP`` property. For example:
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
# Ok: Dependent fixture is different to cleanup
|
||||
set_tests_properties(cleanupFoo PROPERTIES
|
||||
FIXTURES_CLEANUP Foo
|
||||
FIXTURES_REQUIRED Bar
|
||||
)
|
||||
|
||||
# Error: cannot require same fixture as cleanup
|
||||
set_tests_properties(cleanupFoo PROPERTIES
|
||||
FIXTURES_CLEANUP Foo
|
||||
FIXTURES_REQUIRED Foo
|
||||
)
|
||||
|
||||
Cleanup tests will execute even if setup or regular tests for that fixture fail
|
||||
or are skipped.
|
||||
|
||||
See :prop_test:`FIXTURES_REQUIRED` for a more complete discussion of how to use
|
||||
test fixtures.
|
||||
@ -0,0 +1,94 @@
|
||||
FIXTURES_REQUIRED
|
||||
-----------------
|
||||
|
||||
Specifies a list of fixtures the test requires. Fixture names are case
|
||||
sensitive.
|
||||
|
||||
Fixtures are a way to attach setup and cleanup tasks to a set of tests. If a
|
||||
test requires a given fixture, then all tests marked as setup tasks for that
|
||||
fixture will be executed first (once for the whole set of tests, not once per
|
||||
test requiring the fixture). After all tests requiring a particular fixture
|
||||
have completed, CTest will ensure all tests marked as cleanup tasks for that
|
||||
fixture are then executed. Tests are marked as setup tasks with the
|
||||
:prop_test:`FIXTURES_SETUP` property and as cleanup tasks with the
|
||||
:prop_test:`FIXTURES_CLEANUP` property. If any of a fixture's setup tests fail,
|
||||
all tests listing that fixture in their ``FIXTURES_REQUIRED`` property will not
|
||||
be executed. The cleanup tests for the fixture will always be executed, even if
|
||||
some setup tests fail.
|
||||
|
||||
When CTest is asked to execute only a subset of tests (e.g. by the use of
|
||||
regular expressions or when run with the ``--rerun-failed`` command line
|
||||
option), it will automatically add any setup or cleanup tests for fixtures
|
||||
required by any of the tests that are in the execution set.
|
||||
|
||||
Since setup and cleanup tasks are also tests, they can have an ordering
|
||||
specified by the :prop_test:`DEPENDS` test property just like any other tests.
|
||||
This can be exploited to implement setup or cleanup using multiple tests for a
|
||||
single fixture to modularise setup or cleanup logic.
|
||||
|
||||
The concept of a fixture is different to that of a resource specified by
|
||||
:prop_test:`RESOURCE_LOCK`, but they may be used together. A fixture defines a
|
||||
set of tests which share setup and cleanup requirements, whereas a resource
|
||||
lock has the effect of ensuring a particular set of tests do not run in
|
||||
parallel. Some situations may need both, such as setting up a database,
|
||||
serialising test access to that database and deleting the database again at the
|
||||
end. For such cases, tests would populate both ``FIXTURES_REQUIRED`` and
|
||||
:prop_test:`RESOURCE_LOCK` to combine the two behaviours. Names used for
|
||||
:prop_test:`RESOURCE_LOCK` have no relationship with names of fixtures, so note
|
||||
that a resource lock does not imply a fixture and vice versa.
|
||||
|
||||
Consider the following example which represents a database test scenario
|
||||
similar to that mentioned above:
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
add_test(NAME testsDone COMMAND emailResults)
|
||||
add_test(NAME fooOnly COMMAND testFoo)
|
||||
add_test(NAME dbOnly COMMAND testDb)
|
||||
add_test(NAME dbWithFoo COMMAND testDbWithFoo)
|
||||
add_test(NAME createDB COMMAND initDB)
|
||||
add_test(NAME setupUsers COMMAND userCreation)
|
||||
add_test(NAME cleanupDB COMMAND deleteDB)
|
||||
add_test(NAME cleanupFoo COMMAND removeFoos)
|
||||
|
||||
set_tests_properties(setupUsers PROPERTIES DEPENDS createDB)
|
||||
|
||||
set_tests_properties(createDB PROPERTIES FIXTURES_SETUP DB)
|
||||
set_tests_properties(setupUsers PROPERTIES FIXTURES_SETUP DB)
|
||||
set_tests_properties(cleanupDB PROPERTIES FIXTURES_CLEANUP DB)
|
||||
set_tests_properties(cleanupFoo PROPERTIES FIXTURES_CLEANUP Foo)
|
||||
set_tests_properties(testsDone PROPERTIES FIXTURES_CLEANUP "DB;Foo")
|
||||
|
||||
set_tests_properties(fooOnly PROPERTIES FIXTURES_REQUIRED Foo)
|
||||
set_tests_properties(dbOnly PROPERTIES FIXTURES_REQUIRED DB)
|
||||
set_tests_properties(dbWithFoo PROPERTIES FIXTURES_REQUIRED "DB;Foo")
|
||||
|
||||
set_tests_properties(dbOnly dbWithFoo createDB setupUsers cleanupDB
|
||||
PROPERTIES RESOURCE_LOCK DbAccess)
|
||||
|
||||
Key points from this example:
|
||||
|
||||
- Two fixtures are defined: ``DB`` and ``Foo``. Tests can require a single
|
||||
fixture as ``fooOnly`` and ``dbOnly`` do, or they can depend on multiple
|
||||
fixtures like ``dbWithFoo`` does.
|
||||
|
||||
- A ``DEPENDS`` relationship is set up to ensure ``setupUsers`` happens after
|
||||
``createDB``, both of which are setup tests for the ``DB`` fixture and will
|
||||
therefore be executed before the ``dbOnly`` and ``dbWithFoo`` tests
|
||||
automatically.
|
||||
|
||||
- No explicit ``DEPENDS`` relationships were needed to make the setup tests run
|
||||
before or the cleanup tests run after the regular tests.
|
||||
|
||||
- The ``Foo`` fixture has no setup tests defined, only a single cleanup test.
|
||||
|
||||
- ``testsDone`` is a cleanup test for both the ``DB`` and ``Foo`` fixtures.
|
||||
Therefore, it will only execute once regular tests for both fixtures have
|
||||
finished (i.e. after ``fooOnly``, ``dbOnly`` and ``dbWithFoo``). No
|
||||
``DEPENDS`` relationship was specified for ``testsDone``, so it is free to
|
||||
run before, after or concurrently with other cleanup tests for either
|
||||
fixture.
|
||||
|
||||
- The setup and cleanup tests never list the fixtures they are for in their own
|
||||
``FIXTURES_REQUIRED`` property, as that would result in a dependency on
|
||||
themselves and be considered an error.
|
||||
@ -0,0 +1,47 @@
|
||||
FIXTURES_SETUP
|
||||
--------------
|
||||
|
||||
Specifies a list of fixtures for which the test is to be treated as a setup
|
||||
test.
|
||||
|
||||
Fixture setup tests are ordinary tests with all of the usual test
|
||||
functionality. Setting the ``FIXTURES_SETUP`` property for a test has two
|
||||
primary effects:
|
||||
|
||||
- CTest will ensure the test executes before any other test which lists the
|
||||
fixture(s) in its :prop_test:`FIXTURES_REQUIRED` property.
|
||||
|
||||
- If CTest is asked to run only a subset of tests (e.g. using regular
|
||||
expressions or the ``--rerun-failed`` option) and the setup test is not in
|
||||
the set of tests to run, it will automatically be added if any tests in the
|
||||
set require any fixture listed in ``FIXTURES_SETUP``.
|
||||
|
||||
A setup test can have multiple fixtures listed in its ``FIXTURES_SETUP``
|
||||
property. It will execute only once for the whole CTest run, not once for each
|
||||
fixture. A fixture can also have more than one setup test defined. If there are
|
||||
multiple setup tests for a fixture, projects can control their order with the
|
||||
usual :prop_test:`DEPENDS` test property if necessary.
|
||||
|
||||
A setup test is allowed to require other fixtures, but not any fixture listed
|
||||
in its ``FIXTURES_SETUP`` property. For example:
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
# Ok: dependent fixture is different to setup
|
||||
set_tests_properties(setupFoo PROPERTIES
|
||||
FIXTURES_SETUP Foo
|
||||
FIXTURES_REQUIRED Bar
|
||||
)
|
||||
|
||||
# Error: cannot require same fixture as setup
|
||||
set_tests_properties(setupFoo PROPERTIES
|
||||
FIXTURES_SETUP Foo
|
||||
FIXTURES_REQUIRED Foo
|
||||
)
|
||||
|
||||
If any of a fixture's setup tests fail, none of the tests listing that fixture
|
||||
in its :prop_test:`FIXTURES_REQUIRED` property will be run. Cleanup tests will,
|
||||
however, still be executed.
|
||||
|
||||
See :prop_test:`FIXTURES_REQUIRED` for a more complete discussion of how to use
|
||||
test fixtures.
|
||||
@ -1,7 +1,8 @@
|
||||
ANDROID_API
|
||||
-----------
|
||||
|
||||
Set the Android Target API version (e.g. ``15``). The version number
|
||||
must be a positive decimal integer. This property is initialized by
|
||||
the value of the :variable:`CMAKE_ANDROID_API` variable if it is set
|
||||
when a target is created.
|
||||
When :ref:`Cross Compiling for Android with NVIDIA Nsight Tegra Visual Studio
|
||||
Edition`, this property sets the Android target API version (e.g. ``15``).
|
||||
The version number must be a positive decimal integer. This property is
|
||||
initialized by the value of the :variable:`CMAKE_ANDROID_API` variable if
|
||||
it is set when a target is created.
|
||||
|
||||
@ -1,15 +1,27 @@
|
||||
ANDROID_STL_TYPE
|
||||
----------------
|
||||
|
||||
Set the Android property that defines the type of STL support for the project.
|
||||
When :ref:`Cross Compiling for Android with NVIDIA Nsight Tegra Visual Studio
|
||||
Edition`, this property specifies the type of STL support for the project.
|
||||
This is a string property that could set to the one of the following values:
|
||||
``none`` e.g. "No C++ Support"
|
||||
``system`` e.g. "Minimal C++ without STL"
|
||||
``gabi++_static`` e.g. "GAbi++ Static"
|
||||
``gabi++_shared`` e.g. "GAbi++ Shared"
|
||||
``gnustl_static`` e.g. "GNU libstdc++ Static"
|
||||
``gnustl_shared`` e.g. "GNU libstdc++ Shared"
|
||||
``stlport_static`` e.g. "STLport Static"
|
||||
``stlport_shared`` e.g. "STLport Shared"
|
||||
|
||||
``none``
|
||||
No C++ Support
|
||||
``system``
|
||||
Minimal C++ without STL
|
||||
``gabi++_static``
|
||||
GAbi++ Static
|
||||
``gabi++_shared``
|
||||
GAbi++ Shared
|
||||
``gnustl_static``
|
||||
GNU libstdc++ Static
|
||||
``gnustl_shared``
|
||||
GNU libstdc++ Shared
|
||||
``stlport_static``
|
||||
STLport Static
|
||||
``stlport_shared``
|
||||
STLport Shared
|
||||
|
||||
This property is initialized by the value of the
|
||||
variable:`CMAKE_ANDROID_STL_TYPE` variable if it is set when a target is created.
|
||||
:variable:`CMAKE_ANDROID_STL_TYPE` variable if it is set when a target is
|
||||
created.
|
||||
|
||||
@ -1,7 +1,8 @@
|
||||
BUNDLE_EXTENSION
|
||||
----------------
|
||||
|
||||
The file extension used to name a :prop_tgt:`BUNDLE` target on the OS X and iOS.
|
||||
The file extension used to name a :prop_tgt:`BUNDLE`, a :prop_tgt:`FRAMEWORK`,
|
||||
or a :prop_tgt:`MACOSX_BUNDLE` target on the OS X and iOS.
|
||||
|
||||
The default value is ``bundle`` - you can also use ``plugin`` or whatever
|
||||
file extension is required by the host app for your bundle.
|
||||
The default value is ``bundle``, ``framework``, or ``app`` for the respective
|
||||
target types.
|
||||
|
||||
@ -0,0 +1,15 @@
|
||||
LINK_WHAT_YOU_USE
|
||||
---------------------------
|
||||
|
||||
This is a boolean option that when set to ``TRUE`` will automatically run
|
||||
``ldd -r -u`` on the target after it is linked. In addition, the linker flag
|
||||
``-Wl,--no-as-needed`` will be passed to the target with the link command so
|
||||
that all libraries specified on the command line will be linked into the
|
||||
target. This will result in the link producing a list of libraries that
|
||||
provide no symbols used by this target but are being linked to it.
|
||||
This is only applicable to executable and shared library targets and
|
||||
will only work when ld and ldd accept the flags used.
|
||||
|
||||
This property is initialized by the value of
|
||||
the :variable:`CMAKE_LINK_WHAT_YOU_USE` variable if it is set
|
||||
when a target is created.
|
||||
@ -0,0 +1,7 @@
|
||||
VS_SDK_REFERENCES
|
||||
-----------------
|
||||
|
||||
Visual Studio project SDK references.
|
||||
Specify a :ref:`;-list <CMake Language Lists>` of SDK references
|
||||
to be added to a generated Visual Studio project, e.g.
|
||||
``Microsoft.AdMediatorWindows81, Version=1.0``.
|
||||
@ -0,0 +1,320 @@
|
||||
CMake 3.7 Release Notes
|
||||
***********************
|
||||
|
||||
.. only:: html
|
||||
|
||||
.. contents::
|
||||
|
||||
Changes made since CMake 3.6 include the following.
|
||||
|
||||
New Features
|
||||
============
|
||||
|
||||
Platforms
|
||||
---------
|
||||
|
||||
* CMake now supports :ref:`Cross Compiling for Android` with simple
|
||||
toolchain files.
|
||||
|
||||
* The Clang compiler is now supported on AIX.
|
||||
|
||||
Generators
|
||||
----------
|
||||
|
||||
* The :generator:`Ninja` generator learned to conditionally support
|
||||
Fortran when using a ``ninja`` tool that has the necessary features.
|
||||
See generator documentation for details.
|
||||
|
||||
* The :generator:`Ninja` generator learned to produce phony targets
|
||||
of the form ``sub/dir/{test,install,package}`` to drive the build
|
||||
of a subdirectory installation, test or packaging target.
|
||||
This is equivalent to ``cd sub/dir; make {test,install,package}``
|
||||
with :ref:`Makefile Generators`.
|
||||
|
||||
* The :generator:`Visual Studio 15` generator was added. This is
|
||||
experimental and based on Preview 4 because this version of VS
|
||||
has not been released.
|
||||
|
||||
* :ref:`Visual Studio Generators` for VS 2010 and above learned to
|
||||
place ``.natvis`` source files into VS project files properly.
|
||||
|
||||
* The :generator:`Xcode` generator's rudimentary Swift language support
|
||||
learned to honor a new :variable:`CMAKE_Swift_LANGUAGE_VERSION` variable
|
||||
to tell Xcode what version of Swift is used by the source.
|
||||
|
||||
* The :generator:`CodeLite` generator gained a new
|
||||
:variable:`CMAKE_CODELITE_USE_TARGETS` option
|
||||
to change project creation from projects to targets.
|
||||
|
||||
Commands
|
||||
--------
|
||||
|
||||
* The :command:`add_custom_command` command gained a new ``DEPFILE``
|
||||
option that works with the :generator:`Ninja` generator to provide
|
||||
implicit dependency information to the build tool.
|
||||
|
||||
* The :command:`cmake_parse_arguments` command gained a new ``PARSE_ARGV``
|
||||
mode to read arguments directly from ``ARGC`` and ``ARGV#``
|
||||
variables inside a :command:`function` body.
|
||||
|
||||
* The :command:`export` command gained an ``ANDROID_MK`` option
|
||||
to generate ``Android.mk`` files referencing CMake-built
|
||||
libraries as prebuilts for the Android NDK build system.
|
||||
|
||||
* The :command:`file(DOWNLOAD)` and :command:`file(UPLOAD)` commands gained
|
||||
``HTTPHEADER <HTTP-header>`` and ``USERPWD <username>:<password>`` options.
|
||||
|
||||
* The :command:`find_library` and :command:`find_package` commands learned
|
||||
to search in ``lib32/`` directories when the build targets a 32-bit
|
||||
architecture. See the :prop_gbl:`FIND_LIBRARY_USE_LIB32_PATHS` global
|
||||
property.
|
||||
|
||||
* The :command:`find_package` command gained the possibility of
|
||||
sorting compatible libraries by ``NAME`` or by ``NATURAL`` sorting by
|
||||
setting the two new variables :variable:`CMAKE_FIND_PACKAGE_SORT_ORDER`
|
||||
and :variable:`CMAKE_FIND_PACKAGE_SORT_DIRECTION`.
|
||||
|
||||
* The :command:`if` command gained new boolean comparison operations
|
||||
``LESS_EQUAL``, ``GREATER_EQUAL``, ``STRLESS_EQUAL``, ``STRGREATER_EQUAL``,
|
||||
``VERSION_LESS_EQUAL``, and ``VERSION_GREATER_EQUAL``.
|
||||
|
||||
* The :command:`install` command gained an ``EXPORT_ANDROID_MK``
|
||||
subcommand to install ``Android.mk`` files referencing installed
|
||||
libraries as prebuilts for the Android NDK build system.
|
||||
|
||||
* The :command:`string(TIMESTAMP)` and :command:`file(TIMESTAMP)`
|
||||
commands gained support for the ``%a`` and ``%b`` placeholders.
|
||||
These are the abbreviated weekday and month names.
|
||||
|
||||
* The :command:`try_compile` command source file signature now honors
|
||||
configuration-specific flags (e.g. :variable:`CMAKE_<LANG>_FLAGS_DEBUG`)
|
||||
in the generated test project. Previously only the default such flags
|
||||
for the current toolchain were used. See policy :policy:`CMP0066`.
|
||||
|
||||
Variables
|
||||
---------
|
||||
|
||||
* Variable :variable:`CMAKE_FIND_PACKAGE_SORT_ORDER` was added to control
|
||||
the sorting mode of the :command:`find_package` command.
|
||||
|
||||
* Variable :variable:`CMAKE_FIND_PACKAGE_SORT_DIRECTION` was added to control
|
||||
the sorting direction the :command:`find_package` command.
|
||||
|
||||
* :variable:`Toolchain files <CMAKE_TOOLCHAIN_FILE>` may now set a
|
||||
:variable:`CMAKE_<LANG>_FLAGS_INIT` variable to initialize the
|
||||
:variable:`CMAKE_<LANG>_FLAGS` cache entry the first time a language is
|
||||
enabled in a build tree.
|
||||
|
||||
* :variable:`Toolchain files <CMAKE_TOOLCHAIN_FILE>` may now set
|
||||
:variable:`CMAKE_EXE_LINKER_FLAGS_INIT`,
|
||||
:variable:`CMAKE_SHARED_LINKER_FLAGS_INIT`, and
|
||||
:variable:`CMAKE_MODULE_LINKER_FLAGS_INIT` variables to initialize the
|
||||
:variable:`CMAKE_EXE_LINKER_FLAGS`,
|
||||
:variable:`CMAKE_SHARED_LINKER_FLAGS`, and
|
||||
:variable:`CMAKE_MODULE_LINKER_FLAGS` cache entries the first time
|
||||
a language is enabled in a build tree.
|
||||
|
||||
Properties
|
||||
----------
|
||||
|
||||
* On Apple platforms the :prop_tgt:`BUNDLE_EXTENSION` target property
|
||||
now also applies to Frameworks and App Bundles.
|
||||
|
||||
* A :prop_dir:`BINARY_DIR` directory property was added to get the
|
||||
absolute path to the binary directory corresponding to the source
|
||||
directory on which the property is read.
|
||||
|
||||
* A :prop_dir:`BUILDSYSTEM_TARGETS` directory property was added to
|
||||
get the list of logical buildsystem target names added by the
|
||||
project in a directory.
|
||||
|
||||
* A :prop_tgt:`LINK_WHAT_YOU_USE` target property and supporting
|
||||
:variable:`CMAKE_LINK_WHAT_YOU_USE` variable were introduced
|
||||
to detect (on UNIX) shared libraries that are linked but not
|
||||
needed by running ``ldd -r -u``.
|
||||
|
||||
* A :prop_dir:`SOURCE_DIR` directory property was added to get the
|
||||
absolute path to the source directory associated with a directory.
|
||||
|
||||
* A :prop_dir:`SUBDIRECTORIES` directory property was added to
|
||||
get the list of subdirectories added by a project in a directory.
|
||||
|
||||
* A :prop_tgt:`VS_SDK_REFERENCES` target property was added to tell
|
||||
:ref:`Visual Studio Generators` to reference the named SDKs.
|
||||
|
||||
* A :prop_sf:`VS_TOOL_OVERRIDE` source file property was created to tell
|
||||
:ref:`Visual Studio Generators` what tool to use for a source file.
|
||||
|
||||
* The :prop_tgt:`WINDOWS_EXPORT_ALL_SYMBOLS` target property now applies
|
||||
to executable targets with the :prop_tgt:`ENABLE_EXPORTS` property set.
|
||||
|
||||
* A :prop_sf:`XCODE_FILE_ATTRIBUTES` source file property was
|
||||
added to tell the :generator:`Xcode` generator to generate
|
||||
custom content in the Xcode project attributes for the file.
|
||||
|
||||
Modules
|
||||
-------
|
||||
|
||||
* An :module:`AndroidTestUtilities` module was added to manage transfer
|
||||
of test data to an Android device.
|
||||
|
||||
* The :module:`CheckFortranSourceCompiles` module macro
|
||||
``CHECK_Fortran_SOURCE_COMPILES`` gained a ``SRC_EXT`` option
|
||||
to specify a custom test Fortran source file extension.
|
||||
|
||||
* The :module:`ExternalProject` module gained ``HTTP_USERNAME`` and
|
||||
``HTTP_PASSWORD`` options to set http download credentials.
|
||||
|
||||
* The :module:`ExternalProject` module gained a ``HTTP_HEADER``
|
||||
option to add http download headers.
|
||||
|
||||
* The :module:`FindBISON` module ``BISON_TARGET`` macro learned a new
|
||||
``REPORT_FILE`` option to specify the bison ``--report-file=`` option.
|
||||
|
||||
* The :module:`FindBZip2` module now provides imported targets.
|
||||
|
||||
* A :module:`FindICU` module was introduced to find the International
|
||||
Components for Unicode (ICU) libraries and programs.
|
||||
|
||||
* The :module:`FindMatlab` module learned to find the SIMULINK and MAT
|
||||
components.
|
||||
|
||||
* The :module:`FindMatlab` module :command:`matlab_add_mex` command learned
|
||||
to add executables and modules.
|
||||
|
||||
* The :module:`FindMatlab` module :command:`matlab_add_unit_test` command
|
||||
learned to support inline Matlab test code.
|
||||
|
||||
* The :module:`FindOpenCL` module now provides imported targets.
|
||||
|
||||
* The :module:`FindOpenMP` module learned to detect the OpenMP
|
||||
version (specification date) from the compiler.
|
||||
|
||||
* A :module:`FindVulkan` module was added.
|
||||
|
||||
* The :module:`GenerateExportHeader` module learned a new
|
||||
``CUSTOM_CONTENT_FROM_VARIABLE`` option to specify a variable
|
||||
containing custom content for inclusion in the generated header.
|
||||
|
||||
* The :module:`GNUInstallDirs` module gained a new
|
||||
:command:`GNUInstallDirs_get_absolute_install_dir` command.
|
||||
|
||||
* The :module:`UseJava` module gained APIs to "export" jar targets
|
||||
for use by external CMake projects. See the ``install_jar_exports``
|
||||
and ``export_jars`` functions.
|
||||
|
||||
CTest
|
||||
-----
|
||||
|
||||
* CTest now supports test fixtures through the new :prop_test:`FIXTURES_SETUP`,
|
||||
:prop_test:`FIXTURES_CLEANUP` and :prop_test:`FIXTURES_REQUIRED` test
|
||||
properties. When using regular expressions or ``--rerun-failed`` to limit
|
||||
the tests to be run, a fixture's setup and cleanup tests will automatically
|
||||
be added to the execution set if any test requires that fixture.
|
||||
|
||||
* The :command:`ctest_configure`, :command:`ctest_build`,
|
||||
:command:`ctest_test`, :command:`ctest_coverage`, and :command:`ctest_upload`
|
||||
commands gained a new ``CAPTURE_CMAKE_ERROR`` option to capture any errors
|
||||
that occur as the commands run into a variable and avoid affecting the return
|
||||
code of the :manual:`ctest(1)` process.
|
||||
|
||||
CPack
|
||||
-----
|
||||
|
||||
* CPack gained a ``productbuild`` generator on OS X, configured by
|
||||
the :module:`CPackProductBuild` module.
|
||||
|
||||
* CPack gained a new :variable:`CPACK_PACKAGE_CHECKSUM` variable to
|
||||
enable generation of a checksum file for each package file.
|
||||
|
||||
* The :module:`CPackDeb` module learned to support long file names
|
||||
when archive format is set to GNU tar.
|
||||
See :variable:`CPACK_DEBIAN_ARCHIVE_TYPE`
|
||||
|
||||
* The :module:`CPackIFW` module gained a new
|
||||
:command:`cpack_ifw_add_package_resources` command to include additional
|
||||
resources in the installer binary.
|
||||
|
||||
* The :module:`CPackIFW` module :command:`cpack_ifw_configure_component` and
|
||||
:command:`cpack_ifw_configure_component_group` commands gained a new
|
||||
``USER_INTERFACES`` option to add a list of additonal pages to the IFW
|
||||
installer.
|
||||
|
||||
* The :module:`CPackRPM` module learned to generate debuginfo
|
||||
packages on demand. See :variable:`CPACK_RPM_DEBUGINFO_PACKAGE`
|
||||
and its per component version.
|
||||
|
||||
* The :module:`CPackRPM` module learned to generate source rpm
|
||||
(SRPM) packages on demand. See :variable:`CPACK_RPM_PACKAGE_SOURCES`,
|
||||
:variable:`CPACK_RPM_SOURCE_PKG_BUILD_PARAMS` and
|
||||
:variable:`CPACK_RPM_SOURCE_PKG_PACKAGING_INSTALL_PREFIX`.
|
||||
|
||||
* The CPack NSIS generator now supports
|
||||
:variable:`CPACK_NSIS_<compName>_INSTALL_DIRECTORY`.
|
||||
This can be used to set component specific installation directories.
|
||||
|
||||
* The CPack WIX generator now supports
|
||||
:variable:`CPACK_WIX_SKIP_PROGRAM_FOLDER` to allow specification
|
||||
of a custom absolute installation prefix outside
|
||||
of the ProgramFiles folders.
|
||||
|
||||
* The CPack WIX generator now supports
|
||||
:variable:`CPACK_COMPONENT_<compName>_DISABLED`.
|
||||
This can be used to deselect a component from being installed by default.
|
||||
|
||||
* The CPack WIX generator now supports :variable:`CPACK_WIX_PATCH_FILE`
|
||||
fragments for Feature elements.
|
||||
|
||||
* The CPack WIX generator now supports
|
||||
:variable:`CPACK_WIX_ROOT_FEATURE_TITLE` and
|
||||
:variable:`CPACK_WIX_ROOT_FEATURE_DESCRIPTION` to allow the specification
|
||||
of a custom title and description for the root feature element.
|
||||
|
||||
Other
|
||||
-----
|
||||
|
||||
* :manual:`cmake(1)` gained a ``-E capabilities`` option to provide a
|
||||
machine-readable (JSON) description of the capabilities of the
|
||||
cmake tool (available generators, etc.).
|
||||
|
||||
* A new :manual:`cmake-server(7)` mode was added to provide semantic
|
||||
information about a CMake-generated buildsystem to clients through
|
||||
a JSON protocol. Currently all protocols are experimental and subject
|
||||
to change.
|
||||
|
||||
* The :manual:`cmake(1)` command learned a ``--trace-source=<file>`` option.
|
||||
|
||||
* :manual:`ccmake(1)` learned to support vim-like navigation bindings.
|
||||
|
||||
* :manual:`cmake-gui(1)` gained a button to open the generated project file
|
||||
for :ref:`Visual Studio Generators` and the :generator:`Xcode` generator.
|
||||
|
||||
Deprecated and Removed Features
|
||||
===============================
|
||||
|
||||
* We no longer provide Linux i386 binaries for download from ``cmake.org``
|
||||
for new versions of CMake.
|
||||
|
||||
* Vim support files ``cmake-indent.vim``, ``cmake-syntax.vim``, and
|
||||
``cmake-help.vim`` have been removed in favor of the files now provided
|
||||
from the `vim-cmake-syntax`_ project.
|
||||
|
||||
* Support for building CMake itself with some compilers was dropped:
|
||||
|
||||
* Visual Studio 7.1 and 2005 -- superseded by VS 2008 and above
|
||||
* MinGW.org mingw32 -- superseded by MSYS2 mingw32 and mingw64
|
||||
|
||||
CMake still supports generating build systems for other projects using
|
||||
these compilers.
|
||||
|
||||
Other Changes
|
||||
=============
|
||||
|
||||
* The Fortran dependency scanner learned to support the syntax of
|
||||
`Fortran Submodules`_.
|
||||
|
||||
* Vim support files ``indent/cmake.vim`` and ``syntax/cmake.vim``
|
||||
from the `vim-cmake-syntax`_ project are now distributed with CMake.
|
||||
|
||||
.. _`Fortran Submodules`: http://fortranwiki.org/fortran/show/Submodules
|
||||
.. _`vim-cmake-syntax`: https://github.com/pboettch/vim-cmake-syntax
|
||||
@ -0,0 +1,5 @@
|
||||
ANDROID
|
||||
-------
|
||||
|
||||
Set to ``1`` when the target system (:variable:`CMAKE_SYSTEM_NAME`) is
|
||||
``Android``.
|
||||
@ -1,5 +1,11 @@
|
||||
CMAKE_ANDROID_API
|
||||
-----------------
|
||||
|
||||
Default value for the :prop_tgt:`ANDROID_API` target property.
|
||||
See that target property for additional information.
|
||||
When :ref:`Cross Compiling for Android with NVIDIA Nsight Tegra Visual Studio
|
||||
Edition`, this variable may be set to specify the default value for the
|
||||
:prop_tgt:`ANDROID_API` target property. See that target property for
|
||||
additional information.
|
||||
|
||||
Otherwise, when :ref:`Cross Compiling for Android`, this variable provides
|
||||
the Android API version number targeted. This will be the same value as
|
||||
the :variable:`CMAKE_SYSTEM_VERSION` variable for ``Android`` platforms.
|
||||
|
||||
@ -1,5 +1,19 @@
|
||||
CMAKE_ANDROID_ARCH
|
||||
------------------
|
||||
|
||||
Default value for the :prop_tgt:`ANDROID_ARCH` target property.
|
||||
See that target property for additional information.
|
||||
When :ref:`Cross Compiling for Android with NVIDIA Nsight Tegra Visual Studio
|
||||
Edition`, this variable may be set to specify the default value for the
|
||||
:prop_tgt:`ANDROID_ARCH` target property. See that target property for
|
||||
additional information.
|
||||
|
||||
Otherwise, when :ref:`Cross Compiling for Android`, this variable provides
|
||||
the name of the Android architecture corresponding to the value of the
|
||||
:variable:`CMAKE_ANDROID_ARCH_ABI` variable. The architecture name
|
||||
may be one of:
|
||||
|
||||
* ``arm``
|
||||
* ``arm64``
|
||||
* ``mips``
|
||||
* ``mips64``
|
||||
* ``x86``
|
||||
* ``x86_64``
|
||||
|
||||
@ -0,0 +1,17 @@
|
||||
CMAKE_ANDROID_ARCH_ABI
|
||||
----------------------
|
||||
|
||||
When :ref:`Cross Compiling for Android`, this variable specifies the
|
||||
target architecture and ABI to be used. Valid values are:
|
||||
|
||||
* ``arm64-v8a``
|
||||
* ``armeabi-v7a``
|
||||
* ``armeabi-v6``
|
||||
* ``armeabi``
|
||||
* ``mips``
|
||||
* ``mips64``
|
||||
* ``x86``
|
||||
* ``x86_64``
|
||||
|
||||
See also the :variable:`CMAKE_ANDROID_ARM_MODE` and
|
||||
:variable:`CMAKE_ANDROID_ARM_NEON` variables.
|
||||
@ -0,0 +1,7 @@
|
||||
CMAKE_ANDROID_ARM_MODE
|
||||
----------------------
|
||||
|
||||
When :ref:`Cross Compiling for Android` and :variable:`CMAKE_ANDROID_ARCH_ABI`
|
||||
is set to one of the ``armeabi`` architectures, set ``CMAKE_ANDROID_ARM_MODE``
|
||||
to ``ON`` to target 32-bit ARM processors (``-marm``). Otherwise, the
|
||||
default is to target the 16-bit Thumb processors (``-mthumb``).
|
||||
@ -0,0 +1,6 @@
|
||||
CMAKE_ANDROID_ARM_NEON
|
||||
----------------------
|
||||
|
||||
When :ref:`Cross Compiling for Android` and :variable:`CMAKE_ANDROID_ARCH_ABI`
|
||||
is set to ``armeabi-v7a`` set ``CMAKE_ANDROID_ARM_NEON`` to ``ON`` to target
|
||||
ARM NEON devices.
|
||||
@ -0,0 +1,7 @@
|
||||
CMAKE_ANDROID_NDK
|
||||
-----------------
|
||||
|
||||
When :ref:`Cross Compiling for Android with the NDK`, this variable holds
|
||||
the absolute path to the root directory of the NDK. The directory must
|
||||
contain a ``platforms`` subdirectory holding the ``android-<api>``
|
||||
directories.
|
||||
@ -0,0 +1,13 @@
|
||||
CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION
|
||||
-----------------------------------
|
||||
|
||||
When :ref:`Cross Compiling for Android with the NDK`, this variable
|
||||
may be set to specify the version of the toolchain to be used
|
||||
as the compiler. The variable must be set to one of these forms:
|
||||
|
||||
* ``<major>.<minor>``: GCC of specified version
|
||||
* ``clang<major>.<minor>``: Clang of specified version
|
||||
* ``clang``: Clang of most recent available version
|
||||
|
||||
A toolchain of the requested version will be selected automatically to
|
||||
match the ABI named in the :variable:`CMAKE_ANDROID_ARCH_ABI` variable.
|
||||
@ -0,0 +1,6 @@
|
||||
CMAKE_ANDROID_STANDALONE_TOOLCHAIN
|
||||
----------------------------------
|
||||
|
||||
When :ref:`Cross Compiling for Android with a Standalone Toolchain`, this
|
||||
variable holds the absolute path to the root directory of the toolchain.
|
||||
The specified directory must contain a ``sysroot`` subdirectory.
|
||||
@ -1,5 +1,36 @@
|
||||
CMAKE_ANDROID_STL_TYPE
|
||||
----------------------
|
||||
|
||||
Default value for the :prop_tgt:`ANDROID_STL_TYPE` target property.
|
||||
See that target property for additional information.
|
||||
When :ref:`Cross Compiling for Android with NVIDIA Nsight Tegra Visual Studio
|
||||
Edition`, this variable may be set to specify the default value for the
|
||||
:prop_tgt:`ANDROID_STL_TYPE` target property. See that target property
|
||||
for additional information.
|
||||
|
||||
When :ref:`Cross Compiling for Android with the NDK`, this variable may be
|
||||
set to specify the STL variant to be used. The value may be one of:
|
||||
|
||||
``none``
|
||||
No C++ Support
|
||||
``system``
|
||||
Minimal C++ without STL
|
||||
``gabi++_static``
|
||||
GAbi++ Static
|
||||
``gabi++_shared``
|
||||
GAbi++ Shared
|
||||
``gnustl_static``
|
||||
GNU libstdc++ Static
|
||||
``gnustl_shared``
|
||||
GNU libstdc++ Shared
|
||||
``c++_static``
|
||||
LLVM libc++ Static
|
||||
``c++_shared``
|
||||
LLVM libc++ Shared
|
||||
``stlport_static``
|
||||
STLport Static
|
||||
``stlport_shared``
|
||||
STLport Shared
|
||||
|
||||
The default value is ``gnustl_static``. Note that this default differs from
|
||||
the native NDK build system because CMake may be used to build projects for
|
||||
Android that are not natively implemented for it and use the C++ standard
|
||||
library.
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in new issue