Create a <LANG>_INCLUDE_WHAT_YOU_USE target property (initialized by a
CMAKE_<LANG>_INCLUDE_WHAT_YOU_USE variable) to specify an IWYU command
line to be run along with the compiler.
The find_package command, on Windows, has always searched build trees
recently visited by cmake-gui (or CMakeSetup at one time). This was
done when the command was created with the intention of simplifying
workflows involving building multiple dependent projects. However,
this behavior depends on recent developer interaction and therefore
can create different find results based on transient system states.
It can lead to surprising results and user confusion.
Since this behavior was first added CMake has gained many more search
options, better error messages when a package is not found, and a
package registry. The latter in particular allows projects to make
their build trees available for dependent projects to find without
user intervention. Therefore the originally intended workflow can
be achieved in other, more stable ways.
After the above evoluion of find_package we have now decided that
the magic search-where-cmake-gui-was behavior does more harm than
good. Drop it. We do not need a policy for this behavior change
because it only affects interactive use.
Use the KWSys Process "MergeOutput" option to give the child process
the same pipe (or file) for both stdout and stderr. This allows
natural merging of stdout and stderr together instead of merging
on arbitrary buffered read boundaries as before.
5731fb2e ctest_build: mention CTEST_BUILD_COMMAND in the docs
753da8c6 ctest_build: update the default target documentation
5ab896ae ctest_build: spruce up the documentation a bit
This reverts commit 242c3966 (add_custom_command: Diagnose
MAIN_DEPENDENCY limitation, 2015-03-09) and the follow up commit
b372a99a (UseSWIG: Do not use MAIN_DEPENDENCY on custom commands,
2015-03-26).
I misdiagnosed the underlying issue that prompted creation of policy CMP0057.
The actual issue surfaces when a single custom command's MAIN_DEPENDENCY
is listed in more than one target; this issue will have to be addressed
independently.
The previous example for CMP0054 did not show how critical the policy is
since the result is the same in both cases (NEW and OLD behavior).
Instead show an example when the policy does make a difference.
Add sections to the cmake-buildsystem(7) manual and cross-reference
them with relevant variables and target properties. This avoids
duplicating the information and allows it to be more detailed.
Many projects put their project() call first, but the actions taken
by this command can be influenced by policies and other information
set by a call to cmake_minimum_required. Document in each of these
two commands that cmake_minimum_required should be called first.
Suggested-by: Alan W. Irwin
The documentation of this variable in the CTest module is outdated
and has been superseded by the ctest(1) manual. In particular, the
latter mentions that it works with the Ninja generator as well as
makefile generators. Remove the documentation from the CTest module
and replace it with a link to the main variable documentation (which
already references the ctest(1) manual).
66b641f4 Help: Add notes for topic 'add-GreenHills-MULTI-generator'
48004d9d Add a 'Green Hills MULTI' generator on Windows
051d8be1 cmLocalGenerator: Constify some cmTarget and cmGeneratorTarget arguments
Green Hills MULTI is an IDE for embedded real-time systems. The IDE's
product page can be found here:
http://www.ghs.com/products/MULTI_IDE.html
It supports cross compiling on ARM, Intel x86, and other architectures
with various operating systems. The IDE exists on Linux and Windows
host systems, but CMake will currently only generate the project files
on Windows host systems.
The UPPERCASE name was inconsistent with config-packages, the
find_dependency macro, and even FPHSA itself, which expects
components to be specified with names matching ExactCase.
The FOUND_VAR was only permitted to have two possible values, and
now both are set for compatibility. Document it as obsolete, and
adjust the code for the same. Users of the variable should just
remove it.
We never implemented them for VS 11 (2012), 12 (2013), or 14 (2015).
For VS 10 (2010) the reload macro does not work correctly when run from
inside a build launched through the IDE because stopping the build kills
the CMake that is driving the reload. Fortunately VS >= 10 know how to
reload the whole solution anyway.
The GITUpdateCustom and P4UpdateCustom options take only one command
line with all arguments as a ;-list, not a ;-list of multiple command
lines. Fix the incorrect documentation originally added by commit
v3.1.0-rc1~463^2 (Help: Document ctest dashboard client usage,
2014-05-30).
882f48e5 Link libraries by full path even in implicit directories
318cd370 Help: Add link target for Find Modules section of cmake-developer.7
1535dcd8 Tests: Teach RunCMake to optionally merge command output to stdout
When CMP0003 was first introduced we wanted to link all libraries by
full path. However, some projects had problems on platforms where
find_library would find /usr/lib/libfoo.so when the project really
wanted to link to /usr/lib/<arch>/libfoo.so and had been working by
accident because pre-CMP0003 behavior used -lfoo to link.
We first tried to address that in commit v2.6.0~440 (Teach find_library
to avoid returning library paths in system directories, 2008-01-23) by
returning just "foo" for libraries in implicit link directories. This
caused problems for projects expecting find_library to always return a
full path. We ended up using the solution in commit v2.6.0~366 (...
switch library paths found in implicit link directories to use -l,
2008-01-31). However, the special case for libraries in implicit link
directories has also proven problematic and confusing.
Introduce policy CMP0060 to switch to linking all libraries by full path
even if they are in implicit link directories. Explain in the policy
documentation the factors that led to the original approach and now to
this approach.
Prefix test commands with the CROSSCOMPILING_EMULATOR property
for target executables. This allows test suites to be run on the host
when crosscompiling.
If the CMAKE_CROSSCOMPILING_EMULATOR variable is defined, and
CMAKE_CROSSCOMPILING is TRUE, then use CMAKE_CROSSCOMPILING_EMULATOR to run
the try_run executables. This prevents the need to populate
TryRunResults.cmake when cross compiling.
Extend sentences in other documentation linking to this manual to
say that it has a list of supported compilers.
Co-Author: Brad King <brad.king@kitware.com>
Add CROSSCOMPILING_EMULATOR target property for executables. This is used by
subsequent patches to run exectuables created for the target system when
crosscompiling. The property is initialized by the
CMAKE_CROSSCOMPILING_EMULATOR variable when defined.
6f82b5e8 Help: Link to properties in set_tests_properties.
66f5af29 Help: Link to properties in set_directory_properties docs.
f7dd3f7c Help: Add link in set_source_files_properties command docs.
3b256173 Help: Shorten too-long title marker.
8fc3a2fb Help: Add references to cmake-property sections.
Organize the documentation into subsections to separate the signatures.
Refactor the discussion of allowed link items into bullet points and
expand into more detail on each.
XAML files are by default of type Page in the vcxproj and can be
overriden by setting the VS_XAML_TYPE property. The .cpp and .h file
of the same name are automatically added as depending on the XAML file.
New VSXaml test builds a basic XAML WindowsStore 8.1 app with VS2013.
3af13782 Help: Update discussion of relocable packages in cmake-packages(7)
227992c3 Help: Reorganize and refine discussion of relocatable packages
031d894f Help: Place relocatable package notes in their own subsections
6e331ce9 Help: Fix typo in cmake-packages(7) manual
ba9b9d79 Help: Fix syntax in non-relocatable usage requirements example
Many places in our documentation refer to "Makefile Generators" or
"Visual Studio" generators as a group of generators. Give such
places a linkable document section to reference since they cannot
cross-reference the individual generators in the groups.
Explain at the beginning of the section the requirements for a package
to be relocatable to justify the rest of the section content.
Generalize example to use fictional package names instead of real ones,
especially because FindBoost provides no alternative yet. Reword the
discussion to represent the preferred approach as "ideal" but also
suggest workarounds when find modules do not provide the imported
targets.
Re-organize the content added to the cmake-packages(7) manual by
* commit v3.0.0-rc1~184^2 (Help: Document export(EXPORT) in the
cmake-packages manual, 2013-12-23),
* commit v3.0.0-rc1~154^2~1 (Help: Add notes about relocatability
of config-file packages, 2014-01-07), and
* commit v3.2.0-rc1~345^2 (Help: Warn that paths should not be used
in INTERFACE_ build properties, 2014-11-22).
These commits broke the natural flow of the original manual and made
wording after the new content make less sense. Move the content into
new subsections to restore the flow of the original manual and to
make explicitly the purpose of the new content.
Shorten the relocatable usage requirement "warnings". Refer to the
new cmake-packages(7) manual subsection to reduce duplication. Also
clarify the distinction between paths to library dependencies and
paths to their header files.
These notes apply only for the use case of creating a package for
redistribution on machines other than that where it is built. Clarify
this to readers by placing the discussion in dedicated sections titled
accordingly.
Beginning in CUDA 5.5 a static version of the cuda runtime library
became available. Since nvcc defaults to using this library over the
shared version, FindCUDA will also default to using this version. There
are many advantages to using the static version (most importantly to
avoid conflicts with multiple versions when building a CUDA based
library). Offer a CUDA_USE_STATIC_CUDA_RUNTIME option to control
this behavior.
Add policy CMP0059 to cover this change. The property has been
deprecated since CMake 2.4 anyway.
This will help clean up cmMakefile -- the DefineFlagsOrig member should
not need to exist.
Much of the information in the old set() command documentation is now
covered in the cmake-language(7) manual. Rewrite the documentation
with this in mind. Split up the signatures for each kind of variable
into different subsections.
Brad King
Konstantin Podsvirov
Stephen Kelly
Raffi Enficiaud
Ben Boeckel
Robert Goulet
Nils Gladitz
Tamás Kenéz
Geoff Viola
Matt McCormick
Robert Maynard
Gilles Khouzam
James Bigler