Users of the new target_compile_features command are expected to
check the existence of the CMAKE_CXX_COMPILE_FEATURES variable before
attempting to use it to require features.
3b673586 CMP0052: Make the warning message more informative.
5baa8159 CMP0052: Test that include dirs in install locations cause no warnings.
9e0b3153 CMP0052: Do not warn when include dir is not in source or build tree
When the policy was added by commit 783bce29 (Export: Disallow exported
interface includes in src/build tree, 2014-03-31) it accidentally left a
code path that would warn when the include dir is in the install tree
but *not* in the source or build tree. Fix that.
As explained in cmVisualStudio10TargetGenerator::WriteSource comments,
VS tools append relative paths to the current directory, e.g.
c:\path\to\current\dir\..\..\..\relative\path\to\source.c
and fail if this is over 250 charaters or so. Previously we used a full
path only if no relative path could be constructed with a leading "../"
sequence that does not escape the source or build tree. This means that
long relative paths can be generated when the build tree is inside the
source tree, and can cause build failures due to the above path
concatenation problem.
Teach cmVisualStudio10TargetGenerator::ConvertPath to ask the Convert
method to honor CMAKE_USE_RELATIVE_PATHS. This will cause it to use
full paths by default but still give users the option of getting the
relative paths when possible.
Suggested-by: Josh Green <inbilla@gmail.com>
f21ac16e Replace MATCHES test on numbers with EQUAL test
7eacbaed Replace MATCHES ".+" tests with NOT STREQUAL ""
3a71d34c Use CMAKE_SYSTEM_NAME instead of CMAKE_SYSTEM where sufficient
b0b4b460 Remove .* expressions from beginning and end of MATCHES regexs
5bd48ac5 Replace string(REGEX REPLACE) with string(REPLACE) where possible
2622bc3f Clean up usage of if(... MATCHES regex) followed string(REGEX REPLACE regex)
97f2b7f5 Ninja: set correct LANGUAGE_COMPILE_FLAGS when linking
49fcffc6 Ninja: cmake formatting, make code more readable
b735c8cb MinGW: link like on Unix and use compile flags when linking
Replace it by cmStandardIncludes.h which drags in the proper header depending
on what the compiler provides to fix this error:
CMake/Source/cmExtraCodeLiteGenerator.cxx:27: sstream: No such file or directory
OpenBSD defines Elf64_Dyn::d_tag to be of an unsigned type, which differs from
what most other platforms do and what is the case for 32 bit. To have the tag
as unsigned makes sense, but this causes a compilation warning:
/.../CMake/Source/cmELF.cxx: In member function 'const cmELF::StringEntry* cmELFInternalImpl<Types>::GetDynamicSectionString(int) [with Types = cmELFTypes64]':
/.../CMake/Source/cmELF.cxx:945: instantiated from here
/.../CMake/Source/cmELF.cxx:668: warning: comparison between signed and unsigned integer expressions
Add an explicit typedef to cast the value to for 32 and 64 bit. That type is
unsigned and has the proper length for both platforms so no information is
lost. Explicitely cast both arguments before comparing them to avoid the
warning in all situations.
The matches have already been calculated and can simply be taken from
CMAKE_MATCH_n variables. This avoids multiple compilations of the same or very
similar regular expressions.
Since commit e5da9e51 (cmTarget: Allow any generator expression in
SOURCES property., 2014-03-18), source files are computed by
true evaluation of generator expressions, including TARGET_OBJECTS.
This evaluation requires the presence of cmGeneratorTarget objects
since commit bf98cc25 (Genex: Evaluate TARGET_OBJECTS as a normal
expression., 2014-02-26).
Ensure that we don't attempt to evaluate the TARGET_OBJECTS generator
expression at configure-time, as can happen if CMP0024 or CMP0026
are OLD. Use old-style parsing of the source item to extract
object target names in that case.
Avoid calling GetProperty("SOURCES") to bypass warnings from CMP0051.
Refactor existing logic in GetLanguages which is similar in intent to
the new GetSourceFiles code.
Allow directories in the source tree or build tree only if the
install tree is a subdirectory of the source tree or build tree,
as appropriate.
Re-use the test files in the RunCMake.include_directories test
to run in multiple scenarios. Bump the required CMake version
in the test to 3.0 to ensure that the new policy warnings are
emitted correctly.
The AddSource method accepts one file and tries to avoiding adding
it to the sources-list of the target if it already exists. This
involves creating many cmSourceFileLocation objects for matching
on existing files, which is an expensive operation.
Avoid the searching algorithm by appending the new sources as one
group. Generate-time processing of source files will ensure
uniqueness.
Add a new AddTracedSources for this purpose. The existing
AddSources method must process the input for policy CMP0049, but
as these source filenames come from cmSourceFile::GetFullPath(),
we can forego that extra processing.
Computing the language involves computing the source files, which
is an expensive operation. It requires calling
cmMakefile::GetOrCreateSource many times, which involves creating
and matching on many cmSourceFileLocation objects.
Source files of a target may depend on the head-target and the
config as of commit e6971df6 (cmTarget: Make the source files depend
on the config., 2014-02-13). The results are cached for each context
as of commit c5b26f3b (cmTarget: Cache the cmSourceFiles in
GetSourceFiles., 2014-04-05).
Each target in the build graph causes language computation of all
of its dependents with itself as the head-target. This means that
for 'core' libraries on which everything depends, the source files
are computed once for every transitive target-level-dependee and
the result is not cached because the head-target is different. This
was observed in the VTK buildsystem.
Short circuit the computation for targets which have a source-list
that is independent of the head-target. If the source-list has
already been computed and the generator expression evaluation
reports that it was context-independent, return the only source-list
already cached for the target. Reset the short-circuit logic when
sources are added and when the link libraries are re-computed.
Follow up commit 1de08685 (cmSystemTools: Restore unreachable return to
silence warnings, 2014-04-02) by excluding the unreachable return on the
HP compiler as well as Clang. Both recognize that it is unreachable and
warn.
Expect cxx_variadic_templates to implement N2555.
N2555 is essentially a bugfix and predates most compiler releases which
aimed to experimentally support variadic templates.
This can be used to set the compiler features required by particular
targets. An error is issued at CMake time if the compiler does not
support the required feature. If a language dialect flag is required
by the features used, that will be added automatically.
Base the target_compile_features command on cmTargetPropCommandBase. This
gives us 'free' handling of IMPORTED, ALIAS, INTERFACE, non-compilable
and missing targets.
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.
Record the availability of this feature for GNU 4.8 on (UNIX AND
NOT APPLE) only. In the future, availability can be recorded for
earlier GNU, for other platforms and for other compilers. Initially
the affected configurations are as restricted as possible to allow
for easy testing while extending the features vector in only one
dimension.
The error message when using the set_property API directly is not
very good, but follow up commits will provide origin debugging of
the property and a target_compile_features command which will
provide a configure-time backtrace when possible.
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.
a4e6bf8e cmTarget: Make GetSourceFiles string overload private.
92e2fbe1 cmGeneratorTarget: Trace cmSourceFile objects instead of strings.
c5b26f3b cmTarget: Cache the cmSourceFiles in GetSourceFiles.
eb163f37 cmTarget: Extract a ProcessSourceItemCMP0049 method.
19b7c22d Ninja: Query custom commands once per target, not once per file.
This reverses the decision in commit d38423ec (cmTarget: Add a
method to obtain list of filenames for sources., 2014-03-17). The
cmSourceFile based API is preferred because that avoids creation of
many cmSourceFileLocation objects for matching strings, and the
result is cached by cmTarget.
Avoid calling GetSourceFiles with the same result container multiple
times when tracing target dependencies. The result from the previous
configuration is cached and used later otherwise.
Avoid calling AddSource for each src filename. That involves
checking each entry for uniqueness and creating a separate
generator expression for each one.
Instead, add a single entry for the list of sources. The source
files are passed through a uniqueness filter at generate-time, so
duplicates don't matter so much.
The compilation failed with this error message:
.../Source/cmCryptoHash.cxx: In method `string cmCryptoHash::HashString (const string &)':
.../Source/cmCryptoHash.cxx:41: non-lvalue in unary `&'
This was introduced in 77f60392d9 (stringapi:
Accept strings when MD5 hashing data).
6c190245 Remove extra semicolons from C++ code.
4bef02e7 cmTypeMacro: Add a class to eat the semicolon following the macro use.
ff710539 Remove default labels from fully covered switch statements.
9407174b target_sources: New command to add sources to target.
81ad69e0 Make the SOURCES target property writable.
6e636f2e cmTarget: Make the SOURCES origin tracable.
3676fb49 cmTarget: Allow transitive evaluation of SOURCES property.
e6971df6 cmTarget: Make the source files depend on the config.
df753df9 cmGeneratorTarget: Don't add computed sources to the target.
869328aa cmComputeTargetDepends: Use valid config to compute target depends.
5de63265 Genex: Only evaluate TARGET_OBJECTS to determine target sources.
aa0a3562 cmGeneratorTarget: Compute target objects on demand
042c1c83 cmTarget: Compute languages from object libraries on demand.
fdcefe3c cmGeneratorTarget: Compute consumed object libraries on demand.
c355d108 cmComputeTargetDepends: Track object library depends.
e5da9e51 cmTarget: Allow any generator expression in SOURCES property.
5702e106 cmTarget: Include TARGET_OBJECTS genex in target SOURCES property.
857d30b5 cmGlobalGenerator: Add interface to call ForceLinkerLanguages
28e1d2f8 cmStringCommand: Add GENEX_STRIP subcommand.
bf98cc25 Genex: Evaluate TARGET_OBJECTS as a normal expression.
8cd113ad cmTarget: Store strings instead of cmSourceFile* to represent SOURCES.
4959f341 cmSourceFileLocation: Collapse full path for directory comparisons.
fcc92878 cmSourceFileLocation: Remove unused Update method.
59e8740a cmTarget: Remove AddSourceFile method
26d494ba cmTarget: Use string API to add sources to cmTarget objects.
d38423ec cmTarget: Add a method to obtain list of filenames for sources.
...
13684e2b cmMakefile: Port PolicyOptionalWarningEnabled to string APIs
8018fcca Merge branch 'master' into revise-compiler-id-policies
a41c0a9d Do not warn by default when policy CMP0025 or CMP0047 is not set
d339653e Help: Revise and format policy CMP0025 and CMP0047 docs
e8633e66 VS: Fix /analyze:log flag mapping (#14858)
650199e7 VS: Support mapping flags with values following separately (#14858)
f2a3dd9d cmIDEOptions: Factor FlagMap update out to separate method
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.
Disallow the use of config-specific source files with
the Visual Studio and Xcode generators. They don't have
any way to represent the condition currently.
Use the same common-config API in cmQtAutoGenerators. While
it accepts config-specific files, it doesn't have to support
multiple configurations yet.
Loop over the configs in cmTargetTraceDependencies
and cmGlobalGenerator::WriteSummary and consume all source
files.
Loop over the configs in cmComputeTargetDepends and compute the
object library dependencies for each config.
When config-specifig generator expressions are supported, a target
may have SOURCES:
src1.cpp $<$<CONFIG:Debug>:src2.cpp> $<$<CONFIG:Release>:src3.cpp>
and computation in cmTargetTraceDependencies would add each of the
src2.cpp and src3.cpp sources back to the target without a
config-guard. That would make the sources be used later when
generating the buildsystem, regardless of the configuration.
Avoid calling AddSource on the target with the result of the
GetSourceFiles call.
If CMAKE_BUILD_TYPE is set, and user code contains:
target_link_libraries(myexe prefix_$<$<CONFIG:Debug>:debug>)
then the computation with an empty config was computing a target-level
dependency on a target or library called prefix_, and a dependency
on a target or library called prefix_debug (as expected).
The existing logic skips 'prefix_' because it is not a known target,
and defers to the link-dependencies logic to find the library. The
link-dependencies logic does not incorrectly handle the config as
cmComputeTargetDepends did, and so did not encounter 'prefix_'
during its computation. This likely had no effect on the generated
buildsystem.
The output of this expression may contain macros for IDEs to replace
such as $(Configuration), $(CURRENT_ARCH) etc. To avoid generating
content which is not usable in other contexts, report an error if
there is an attempt to use it in other contexts.
This commit may be reverted in the future if a solution to the
above difference is implemented.
Add a ComputeObjectMapping method to compute the object
names. It takes mapping to populate as an out-parameter so
that it can be extended in the future with parameters
relevant to generator expression evaluation.
Remove the supporting cmGeneratorTarget::AddObject method. It is
no longer needed as the container member is populated directly.
The ComputeObjectMapping method is called whenever objects are
requested from the cmGeneratorTarget. Because the Xcode generator
makes no such request, explicitly invoke the method from that
generator so that the logic of checking for bad sources in object
libraries is executed.
In a follow-up, the UseObjectLibraries usage may be replaced by a
true generator expression evaluator for TARGET_OBJECTS. That
will require generators to use cmGeneratorTarget::GetExternalObjects
which is not currently the case for Xcode and VS generators.
Remove use of UseObjectLibraries from Makefile and Ninja generators. It
is not needed now because those generators use GetExternalObjects
which already contains the objects from object libraries.
The VS10 generator calls both the UseObjectLibraries and the GetExternalObjects
methods. Ensure that duplicates are not created by skipping objects
from object libraries in handling of GetExternalObjects.
Similarly, fix VS6, VS7 and Xcode object handling by skipping
external objects from OBJECT_LIBRARY usage as appropriate.
The error message in the BadSourceExpression1 test is now reported
by the generator expression evaluator, so it has different text.
This method was added in a commit based on a release branch that
pre-dated the std::string API changes. Port the implementation to use
the string APIs instead of c_str().
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.
Brad King
Stephen Kelly
Kitware Robot
Rolf Eike Beer
Peter Kümmel
Jiri Malak
Daniele E. Domenichelli