These policies are triggered by the use of a particular compiler rather
than outdated CMake code in a project. Avoid warning in every project
that enables a language by not displaying the policy warning by default.
Add variable CMAKE_POLICY_WARNING_CMP<NNNN> to control the warning
explicitly; otherwise enable the warning with --debug-output or --trace.
This breaks with strict policy convention because it does not provide
developers with any warning about the behavior change by default.
Existing projects will continue to build without a warning or change in
behavior. When a developer changes the minimum required version of
CMake in a project to a sufficiently high value (3.0), the project will
suddenly get the new compiler id and may break, but at least the
breakage comes with a change to the project rather than the version of
CMake used to build it.
Breaking strict policy convention is worthwhile in this case because
very few projects will be affected by the behavior change but every
project would have to see the warning if it were enabled by default.
Define a new 'CMAKE_CONFIGURE_DEPENDS' directory property that projects
can use to specify input files to the CMake configuration process.
Extend the RunCMake.Configure test to verify that the build system
re-runs CMake when this input changes.
Most callers already have a std::string, on which they called c_str() to pass it
into these methods, which internally converted it back to std::string. Pass a
std::string directly to these methods now, avoiding all these conversions.
Those methods that only pass in a const char* will get the conversion to
std::string now only once.
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.
...
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.
Drop all behavior activated by setting CMAKE_BACKWARDS_COMPATIBILITY to
a value lower than 2.4, and generate an error when projects or the user
attempt to do so. In the error suggest using a CMake 2.8.x release.
Teach cmake_minimum_required to warn about projects that do not require
at least CMake 2.4. They are not supported by CMake >= 3.0.
Replace the documentation of CMAKE_BACKWARDS_COMPATIBILITY with a
reference to policy CMP0001.
Currently, export() is executed at configure-time.
One problem with this is that certain exported properties like
the link interface may not be complete at the point the export() is
encountered leading to an incorrect or incomplete exported
representation. Additionally, the generated IMPORTED_LOCATION
property may even be incorrect if commands following the export()
have an effect on it.
Another problem is that it requires the C++ implementation of cmake
to be capable of computing the exported information at configure time.
This is a limitation on the cleanup and maintenance of the code. At
some point in the future, this limitation will be dropped and more
implementation will be moved from cmTarget to cmGeneratorTarget.
In the common case of custom command dependencies specified via full
path optimize the implementation of GetSourceFileWithOutput using a
(hash) map. This is significantly faster than the existing linear
search. In the non-full-path case fall back to the existing linear
suffix search.
* The ALIAS name must match a validity regex.
* Executables and libraries may be aliased.
* An ALIAS acts immutable. It can not be used as the lhs
of target_link_libraries or other commands.
* An ALIAS can be used with add_custom_command, add_custom_target,
and add_test in the same way regular targets can.
* The target of an ALIAS can be retrieved with the ALIASED_TARGET
target property.
* An ALIAS does not appear in the generated buildsystem. It
is kept separate from cmMakefile::Targets for that reason.
* A target may have multiple aliases.
* An ALIAS target may not itself have an alias.
* An IMPORTED target may not have an alias.
* An ALIAS may not be exported or imported.
9cf3547 Add the INTERFACE_SYSTEM_INCLUDE_DIRECTORIES target property.
1925cff Add a SYSTEM parameter to target_include_directories (#14180)
286f227 Extend the cmTargetPropCommandBase interface property handling.
83498d4 Store system include directories in the cmTarget.
f1fcbe3 Add Target API to determine if an include is a system include.
2679a34 Remove unused variable.
Use constructs similar to those for COMPILE_OPTIONS. This is a little
different because there is a command to remove_definitions(), so
we can't populate the equivalent target property until generate-time
in cmGlobalGenerator.
Entries from the cmMakefile are processed and maintained similarly
to other include directories. The include_directories(SYSTEM)
signature affects all following targets, and all prior targets
in the same makefile.
AddCMakeDependFile and AddCMakeOutputFile both store as std::string
and all calling sites use std::string. So instead of creating more
temporary objects, lets just use std::strings.
This command is similar to add_definitions, in that it affects
the compile options of all targets which follow it. The implementation
is similar to the implementation of the include_directories command,
in that it is based on populating a COMPILE_OPTIONS directory property
and using that to initialize the same property on targets.
Unlike the include_directories command however, the add_compile_options
command does not affect previously defined targets. That is, in
the following code, foo will not be compiled with -Wall, but bar
will be:
add_library(foo ...)
add_compile_options(-Wall)
add_library(bar ...)
Since commit 08cb4fa4 (Process generator expressions in the
INCLUDE_DIRECTORIES property., 2012-09-18), it is possible to use
generator expressions with the include_directories command.
As that command can also have a SYSTEM argument, ensure that the
result of using that argument with generator expressions gives a
sane result.
During configure-time, GetIncludeDirectories may be called too, for example
if using the export() command. As the content can be different, it should
be output each time then.
Otherwise, we get a separate IncludeDirectoriesEntry for each include,
and that causes unnecessary and confusing splitting in the output when
debugging the INCLUDE_DIRECTORIES property.
Historically CMake has always expanded ${} variable references in the
values given to include_directories(), link_directories(), and
link_libraries(). This has been unnecessary since general ${}
evaluation syntax was added to the language a LONG time ago, but has
remained for compatibility with VERY early CMake versions.
For a long time the re-expansion was a lightweight operation because it
was only processed once at the directory level and the fast-path of
cmMakefile::ExpandVariablesInString was usually taken because values did
not have any '$' in them. Then commit d899eb71 (Call
ExpandVariablesInString for each target's INCLUDE_DIRECTORIES,
2012-02-22) made the operation a bit heavier because the expansion is
now needed on a per-target basis. In the future we will support
generator expressions in INCLUDE_DIRECTORIES with $<> syntax, so the
fast-path in cmMakefile::ExpandVariablesInString will no longer be taken
and re-expansion will be very expensive.
Add policy CMP0019 to skip the re-expansion altogether in NEW behavior.
In OLD behavior perform the expansion but improve the fast-path
heuristic to match ${} but not $<>. If the policy is not set then warn
if expansion actually does anything. We expect this to be encountered
very rarely in practice.
In trace mode ('--trace'), any 'elseif' or 'else' commands that are
evaluated as part of a conditional block will be printed. Previously,
only the opening 'if' command of a conditional block was printed.
Add a boolean target property NO_SONAME which may be used to disable
soname for the specified shared library or module even if the platform
supports it. This property should be useful for private shared
libraries or various plugins which live in private directories and have
not been designed to be found or loaded globally.
Replace references to <CMAKE_SHARED_LIBRARY_SONAME_${LANG}_FLAG> and
hard-coded -install_name flags with a conditional <SONAME_FLAG> which is
expanded to the value of the CMAKE_SHARED_LIBRARY_SONAME_${LANG}_FLAG
definition as long as soname supports is enabled for the target in
question. Keep expanding CMAKE_SHARED_LIBRARY_SONAME_${LANG}_FLAG in
rules in case third party projects still use it. Such projects would
not yet use NO_SONAME so the adjacent <TARGET_SONAME> will always be
expanded. Make <TARGET_INSTALLNAME_DIR> NO_SONAME aware as well. Since
-install_name is soname on OS X, this should not be a problem if this
variable is expanded only if soname is enabled.
The Ninja generator performs rule variable substitution only once
globally per rule to put its own placeholders. Final substitution is
performed by ninja at build time. Therefore we cannot conditionally
replace the soname placeholders on a per-target basis. Rather than
omitting $SONAME from rules.ninja, simply do not write its contents for
targets which have NO_SONAME. Since 3 variables are affected by
NO_SONAME ($SONAME, $SONAME_FLAG, $INSTALLNAME_DIR), set them only if
soname is enabled.
Teach cmMakefile::AddCustomCommandToOutput to return the cmSourceFile
instance to which the custom command is attached. Use the return value
instead of separately adding a .rule extension and searching for the
source. Mark CMake-generated .rule files explicitly with a property
instead of trusting the file extension.
d662dff Fix shadowed variable warning on dashboard results
f66e735 Fix compiler warning reported on older Borland dashboard.
d90eed4 Fix compiler error reported on older Borland dashboard.
8233636 Update the documentation regarding INCLUDE_DIRECTORIES.
d899eb7 Call ExpandVariablesInString for each target's INCLUDE_DIRECTORIES
c21db87 Make search paths ordered and unique
22021f0 Remove cmMakefile::GetIncludeDirectories
9106b56 Extract and use the INCLUDE_DIRECTORIES target properties.
840509b Keep the INCLUDE_DIRECTORIES target property up to date.
a4d5f7b Add API to get the ordered includes for a target.
8adaee2 CMake: Eliminate cmMakefile::IncludeDirectories
7620932 Remove include flags memoization.
97a5faa Make it safe to call this method without creating duplicates.
edd5303 Refactor GetIncludeFlags to take includes instead of fetching them
Consider the case motivating commit e01cce28 (Allow add_dependencies()
on imported targets, 2010-11-19). An imported target references a file
generated at build time by a custom target on which it depends. Had the
file been built directly using add_library or add_executable its target
name would have been visible globally. Therefore the imported target
representing the file should be globally visible also.
Teach the IMPORTED signature of add_(executable|library) to accept a new
"GLOBAL" option to make the imported target visible globally.
Brad King
Stephen Kelly
Rolf Eike Beer
Clinton Stimpson
Nicolas Despres
Robert Maynard
Peter Kümmel
Brian Helba
David Cole
Modestas Vainius
Yury G. Kudryashov