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-mode.el DESTINATION ${CMAKE_DATA_DIR}/editors/emacs)
|
||||||
install(FILES cmake.m4 DESTINATION share/aclocal)
|
install(FILES cmake.m4 DESTINATION share/aclocal)
|
||||||
add_subdirectory (bash-completion)
|
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
|
" Vim indent file
|
||||||
" Language: CMake (ft=cmake)
|
" Language: CMake (ft=cmake)
|
||||||
" Author: Andy Cedilnik <andy.cedilnik@kitware.com>
|
" 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_cmake_property
|
||||||
------------------
|
------------------
|
||||||
|
|
||||||
Get a property of the CMake instance.
|
Get a global property of the CMake instance.
|
||||||
|
|
||||||
::
|
::
|
||||||
|
|
||||||
get_cmake_property(VAR property)
|
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``
|
stored in the variable ``VAR``. If the property is not found, ``VAR``
|
||||||
will be set to "NOTFOUND". See the :manual:`cmake-properties(7)` manual
|
will be set to "NOTFOUND". See the :manual:`cmake-properties(7)` manual
|
||||||
for available properties.
|
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
|
ANDROID_API
|
||||||
-----------
|
-----------
|
||||||
|
|
||||||
Set the Android Target API version (e.g. ``15``). The version number
|
When :ref:`Cross Compiling for Android with NVIDIA Nsight Tegra Visual Studio
|
||||||
must be a positive decimal integer. This property is initialized by
|
Edition`, this property sets the Android target API version (e.g. ``15``).
|
||||||
the value of the :variable:`CMAKE_ANDROID_API` variable if it is set
|
The version number must be a positive decimal integer. This property is
|
||||||
when a target is created.
|
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
|
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:
|
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"
|
``none``
|
||||||
``gabi++_static`` e.g. "GAbi++ Static"
|
No C++ Support
|
||||||
``gabi++_shared`` e.g. "GAbi++ Shared"
|
``system``
|
||||||
``gnustl_static`` e.g. "GNU libstdc++ Static"
|
Minimal C++ without STL
|
||||||
``gnustl_shared`` e.g. "GNU libstdc++ Shared"
|
``gabi++_static``
|
||||||
``stlport_static`` e.g. "STLport Static"
|
GAbi++ Static
|
||||||
``stlport_shared`` e.g. "STLport Shared"
|
``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
|
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
|
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
|
The default value is ``bundle``, ``framework``, or ``app`` for the respective
|
||||||
file extension is required by the host app for your bundle.
|
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
|
CMAKE_ANDROID_API
|
||||||
-----------------
|
-----------------
|
||||||
|
|
||||||
Default value for the :prop_tgt:`ANDROID_API` target property.
|
When :ref:`Cross Compiling for Android with NVIDIA Nsight Tegra Visual Studio
|
||||||
See that target property for additional information.
|
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
|
CMAKE_ANDROID_ARCH
|
||||||
------------------
|
------------------
|
||||||
|
|
||||||
Default value for the :prop_tgt:`ANDROID_ARCH` target property.
|
When :ref:`Cross Compiling for Android with NVIDIA Nsight Tegra Visual Studio
|
||||||
See that target property for additional information.
|
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
|
CMAKE_ANDROID_STL_TYPE
|
||||||
----------------------
|
----------------------
|
||||||
|
|
||||||
Default value for the :prop_tgt:`ANDROID_STL_TYPE` target property.
|
When :ref:`Cross Compiling for Android with NVIDIA Nsight Tegra Visual Studio
|
||||||
See that target property for additional information.
|
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