| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Also add a 'CMAKE_ANDROID_API' variable to set the property default.
|
|
|
|
|
|
|
| |
Also add a 'CMAKE_ANDROID_GUI' variable to set the property default
so a project can easily make all executables Android applications.
An Android application executable file has the same extension as a
shared library (.so).
|
|
|
|
|
|
|
|
| |
The MSVC /ZW flag is valid only for C++ sources. Whenever we enable
CompileAsWinRT for the whole target, disable it for all C sources.
Update the documentation of VS_WINRT_COMPONENT to drop the statement
about undefined behavior for non-C++ sources, because it is now
defined as expected.
|
|
|
|
|
|
|
|
| |
Deprecate VS_WINRT_EXTENSIONS and document VS_WINRT_COMPONENT as for VS
generators only. Also define _WINRT_DLL in SHARED libraries in order to
get a .lib produced.
Inspired-by: Paul Annetts <paul@lightunobscured.com>
|
|
|
|
|
|
| |
Document the COMPILE_DEFINITIONS_<Config> properties as deprecated.
Add new sections for deprecated properties and move POST_INSTALL_SCRIPT
and PRE_INSTALL_SCRIPT there as well.
|
|\
| |
| |
| |
| | |
907e422b Help: Explain build/install-tree include dirs in more places (#14946)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Explain how to use $<BUILD_INTERFACE> and $<INSTALL_INTERFACE> directly
in the documentation of the target_include_directories command and
INTERFACE_INCLUDE_DIRECTORIES target property. Otherwise readers need
to notice the link to the cmake-buildsystem(7) manual and find the
example in that to understand the need for these expressions.
Also fix the explanation in cmake-buildsystem(7) to not claim that
relative paths may be used inside a BUILD_INTERFACE expression.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Compilers enable their extensions by default, and disabling them
implicitly can lead to results which are surprising or non-obvious
to debug.
http://public.kitware.com/pipermail/cmake-developers/2014-May/010575.html
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10214
https://www.mail-archive.com/cmake-developers@cmake.org/msg10116.html
(Compiler feature extensions by default, 29 May 2014)
|
| |
| |
| |
| |
| |
| |
| |
| | |
Link to it from the documentation of related properties, variables
and commands.
Extend the cmake-developer(7) documentation with notes on
extending feature support for compilers.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add properties and variables corresponding to CXX equivalents.
Add features for c_function_prototypes (C90), c_restrict (C99),
c_variadic_macros (C99) and c_static_assert (C11). This feature
set can be extended later.
Add a <PREFIX>_RESTRICT symbol define to WriteCompilerDetectionHeader
to conditionally represent the c_restrict feature.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Use the highest standard compile flags available if requested language
version is too new.
This supports use-cases like
set(CMAKE_CXX_STANDARD 14)
# Compiled with -std=c++11 with GNU 4.7, which has no -std=c++14
# or equivalent flag
add_executable(main main.cpp)
This can be used in combination with preprocessor defines which
communicate the availability of certain language features for
optional use.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Extend the interface of the target_compile_features command with
PUBLIC and INTERFACE keywords. Populate the INTERFACE_COMPILER_FEATURES
target property if they are set. Consume the INTERFACE_COMPILER_FEATURES
target property from linked dependent targets to determine the final
required compiler features and the compile flag, if needed.
Use the same pattern of origin-debugging which is used for other
build properties.
|
| |
| |
| |
| |
| |
| | |
Delay validation of the content as a feature if it contains a
generator expression. It will be checked again at generate-time
after evaluation.
|
| |
| |
| |
| |
| |
| |
| | |
Use the contents of it to upgrade the CXX_STANDARD target property,
if appropriate. This will have the effect of adding the -std=c++11
compile flag or other language specification on GNU when that is
needed for the feature.
|
| |
| |
| |
| |
| | |
These are used to determine whether to add -std=c++11, -std=gnu++11
etc flags on the compile line.
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Extend the cmGeneratorExpressionDAGChecker with an interface
returning the name of the top target. Use that to determine
when there is a DAG violation, as required by the RunCMake.Languages
tests.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since commit v2.8.12~437^2~2 (VS: Separate compiler and linker PDB files
2013-04-05) we no longer set /Fd with the PDB_NAME or PDB_OUTPUT_DIRECTORY
properties. Those properties now exclusively handle linker PDB files.
Since STATIC libraries do not link their compiler PDB file becomes more
important. Add new target properties "COMPILE_PDB_NAME[_<CONFIG>]" and
"COMPILE_PDB_OUTPUT_DIRECTORY[_<CONFIG>]" to specify the compiler PDB
file location and pass the value to the MSVC /Fd option.
|
|/
|
|
|
|
|
| |
Move the note about VS 6 into the PDB_NOTE.txt common include file
and include it from the per-config properties too. Also re-word
the note to clarify the separate compiler and linker flags involved
and state explicitly that compiler flags are not affected.
|
|
|
|
| |
Link to the cmake-qt manual.
|
|
|
|
| |
Only the first letter is capitalized. It is marked up.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
The old documentation stated that "all header files" were considered,
which was not true for any sensible definition of "all header files".
Only header files with certain names are considered.
Document the filename patterns matched for parsing.
|
|
|
|
|
|
|
|
|
|
| |
Add documentation entries for variables
CMAKE_OSX_ARCHITECTURES
CMAKE_OSX_DEPLOYMENT_TARGET
CMAKE_OSX_SYSROOT
Explain what each does and when/how they should be set.
|
| |
|
| |
|
|
|
|
|
| |
Also adding documentation for CMAKE_MACOSX_RPATH, and improving
documentation for MACOSX_RPATH.
|
|
|
|
|
| |
Resolve some sentence fragments, remove a copy-pasto from other docs
and use a link to the CMAKE_VISIBILITY_INLINES_HIDDEN variable.
|
|\
| |
| |
| |
| |
| |
| | |
c0897cf Help: Document PDB behavior w.r.t. static libraries explicitly (#14600)
09c05f3 Help: Format PDB_NAME and PDB_OUTPUT_DIRECTORY documentation
cb7b907 Help: Document CMAKE_PDB_OUTPUT_DIRECTORY_<CONFIG> variable
|
| |
| |
| |
| |
| |
| | |
Document PDB_NAME and PDB_OUTPUT_DIRECTORY as applying only to shared
libraries and executables. Add an explicit note to explain why they
do not work for static libraries.
|
| |
| |
| |
| | |
Add reStructuredText inline markup.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Transitively consume the property from linked dependents.
Implement configuration-specific support by following the pattern
set out for compile definitions and includes in cmQtAutoGenerators.
Implement support for origin-tracking with CMAKE_DEBUG_TARGET_PROPERTIES.
This is motivated by the needs of KDE, which provides a separate
translation system based on gettext instead of the Qt linguist
translation system. The Qt uic tool provides command line options
for configuring the method used to translate text, and to add an
include directive to the generated file to provide the method.
http://thread.gmane.org/gmane.comp.kde.devel.frameworks/7930/focus=7992
Implement the interface to provide the uic options as a usage-requirement
on the KI18n target, as designed for KDE.
|
|\
| |
| |
| |
| | |
7605e37 Ninja: job pool support for compiling and linking
|
| |
| |
| |
| |
| | |
Could be tested by setting the environment
variable NINJA_STATUS=[%r]
|
|/
|
|
|
| |
Test this by generating files with a custom target, which moc
requires to be present when it is run.
|
|
|
|
|
|
|
| |
Apply the changes from commit 603fe925 (Fix summary documentation of
INTERFACE_LINK_LIBRARIES, 2013-11-04) and commit 0aa97b6b (Fix spelling
in INTERFACE_LINK_LIBRARIES documentation, 2013-11-04) to the new
location of the same documentation.
|
|
|
|
| |
Note that relative paths should not be added directly.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
9c87d9c Add automatic rcc invocation for Qt.
84218e1 Add automatic uic invocation for Qt.
94a0ca6 Record which files are skipped by automoc.
18fb758 Run the main executable created in the autogen tests.
e485ba1 Rename the QtAutomoc tests to QtAutogen.
7ce65c3 Add extra checks for the AUTOMOC target property.
32771fc Update output messages for generic use.
f371ab5 Rename RunAutomoc to RunAutogen.
85b3d6e Extract an SetupAutoMocTarget method.
ca124a1 Rename the AutomocInfo.cmake file to be more generic.
a342c9f Move some makefile definitions up away from moc-specific code.
98632ef Add the AUTOGEN_TARGETS_FOLDER and obsolete AUTOMOC_TARGETS_FOLDER.
63378ba Rename some variables to reflect broader scope.
97f1aa3 Rename method to reflect generic use.
4abb111 Rename local variable to reflect generic use.
03878c9 Move variable set to where it is used.
...
|
| |
| |
| |
| |
| | |
This replaces the need to invoke qt4_add_resources by allowing
adding the source .qrc file directly to the target sources.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The source files are already processed by cmQtAutomoc to look for
moc includes, so extend that to also look for ui_ includes and
find corresponding .ui files to process.
This replaces the need to invoke qt4_wrap_ui().
As the ui files are not likely to be part of the SOURCES of the
target, store the options associated with them separately in the
cmMakefile for querying during the autogen run.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
ff6c401 cmTarget: Add interface for compatible numeric properties
e4e20c1 cmTarget: Add enumeration for consistency to expect from properties.
9877769 cmTarget: Assign consistent content back to the property being evaluated.
816b4a8 cmTarget: Make consistentProperty return consistent content.
030800a cmTarget: Add a template to create correct implied content.
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When using the boost MPL library, one can set a define to increase
the limit of how many variadic elements should be supported. The
default for BOOST_MPL_LIMIT_VECTOR_SIZE is 20:
http://www.boost.org/doc/libs/1_36_0/libs/mpl/doc/refmanual/limit-vector-size.html
If the foo library requires that to be set to 30, and the independent
bar library requires it to be set to 40, consumers of both need to set
it to 40.
add_library(foo INTERFACE)
set_property(TARGET foo PROPERTY INTERFACE_boost_mpl_vector_size 30)
set_property(TARGET foo PROPERTY COMPATIBLE_INTERFACE_NUMBER_MAX boost_mpl_vector_size)
target_compile_definitions(foo INTERFACE BOOST_MPL_LIMIT_VECTOR_SIZE=$<TARGET_PROPERTY:boost_mpl_vector_size>)
add_library(bar INTERFACE)
set_property(TARGET bar PROPERTY INTERFACE_boost_mpl_vector_size 40)
# Technically the next two lines are redundant, but as foo and bar are
# independent, they both set these interfaces.
set_property(TARGET bar PROPERTY COMPATIBLE_INTERFACE_NUMBER_MAX boost_mpl_vector_size)
target_compile_definitions(bar INTERFACE BOOST_MPL_LIMIT_VECTOR_SIZE=$<TARGET_PROPERTY:boost_mpl_vector_size>)
add_executable(user)
target_link_libraries(user foo bar)
Because the TARGET_PROPERTY reads the boost_mpl_vector_size property
from the HEAD of the dependency graph (the user target), and because
that property appears in the COMPATIBLE_INTERFACE_NUMBER_MAX of
the dependencies of the user target, the maximum value for it is
chosen for the compile definition, ie, 40.
There are also use-cases for choosing the minimum value of a number.
In Qt, deprecated API can be disabled by version. Setting the
definition QT_DISABLE_DEPRECATED_BEFORE=0 disables no deprecated
API. Setting it to 0x501000 disables API which was deprecated before
Qt 5.1 etc.
If two dependencies require the use of API which was deprecated in
different Qt versions, then COMPATIBLE_INTERFACE_NUMBER_MIN can be
used to ensure that both can compile.
|
|/
|
|
| |
dependee -> depender.
|
|
|
|
|
|
|
| |
These two target properties serve the same purpose for different versions
of Visual Studio. Document the versions covered by each property.
Reported-by: mar.na@t-online.de
|
|
|
|
|
|
|
|
|
| |
Generator expressions are supported in many places and are a distinct
concept worthy of their own manual page. The old builtin documentation
was previously represented by preprocessor macros to generate it into
each place that supports them. Factor out the duplicate content into a
dedicated cmake-generator-expressions manual page and reference it from
each original location.
|
|
|
|
|
|
|
| |
The COMPILE_DEFINITIONS escaping disclaimer was represented in builtin
documentation using a preprocessor macro. Factor the duplicate content
out into a separate .txt file and include it in each document with the
reStructuredText include directive.
|