This target type only contains INTERFACE_* properties, so it can be
used as a structural node. The target-specific commands enforce
that they may only be used with the INTERFACE keyword when used
with INTERFACE_LIBRARY targets. The old-style target properties
matching LINK_INTERFACE_LIBRARIES_<CONFIG> are always ignored for
this target type.
The name of the INTERFACE_LIBRARY must match a validity generator
expression. The validity is similar to that of an ALIAS target,
but with the additional restriction that it may not contain
double colons. Double colons will carry the meaning of IMPORTED
or ALIAS targets in CMake 2.8.13.
An ALIAS target may be created for an INTERFACE library.
At this point it can not be exported and does not appear in the
buildsystem and project files are not created for them. That may
be added as a feature in a later commit.
The generators need some changes to handle the INTERFACE_LIBRARY
targets returned by cmComputeLinkInterface::GetItems. The Ninja
generator does not use that API, so it doesn't require changes
related to that.
In buggy code like
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/out.h
MAIN_DEPENDENCY ${CMAKE_CURRENT_SOURCE_DIR}/out.h.in
...)
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/out.h
...)
that has more than one rule to generate the same output CMake has always
used the first rule. However, since commit 2268c41a (Optimize custom
command full-path dependency lookup, 2013-08-06) we update the map from
output to cmSourceFile for every rule generating an output, effectively
keeping the last command instead of the first.
Fix this regression by checking for each map update if the output
already has an entry. If so, keep only the original entry. The VS 8
generator triggers this with a special case for generate.stamp rules
that differ between ZERO_CHECK and normal targets, so do not warn for
now. Leave a TODO comment for warning in the future.
Since commit ad502502 (cmMakefile: Track configured files so we can
regenerate them, 2013-06-18) cmMakefile::ConfigureFile records the
configured file as an output file generated by CMake. The intention is
that for make and ninja we can re-run CMake when one of the files it
generates goes missing. However, files configured temporarily in
CMakeTmp directories by Check* modules do not live past the CMake
invocation.
We have to also track input files to the configure command. In theory
the input to a configure command could it self be a file that is going
to be deleted later (output from a custom command or configure_file).
Since commit ad502502 (cmMakefile: Track configured files so we can
regenerate them, 2013-06-18) cmMakefile::ConfigureFile records the
configured file as an output file generated by CMake. The intention is
that for make and ninja we can re-run CMake when one of the files it
generates goes missing. However, files configured temporarily in
CMakeTmp directories by Check* modules do not live past the CMake
invocation.
Teach cmMakefile::FinalPass to stop tracking files that don't
exist after we are finished generation.
b93982f Merge branch 'dev/fix-variable-watch-crash' into cmake-syntax
c50f7ed cmListFileLexer: Modify flex output to avoid Borland warning
bf73264 Warn about unquoted arguments that look like long brackets
58e5241 Warn about arguments not separated by whitespace
e75b69f cmListFileCache: Convert CMake language parser to class
e945949 Add RunCMake.Syntax test cases for command invocation styles
0546484 cmListFileArgument: Generalize 'Quoted' bool to 'Delimeter' enum
28685ad cmListFileLexer: Split normal and legacy unquoted arguments
1eafa3e cmListFileLexer: Fix line number after backslash in string
f3155cd Add RunCMake.Syntax test to cover argument parsing
Replace the boolean value that indicates whether an argument is unquoted
or quoted with a generalized enumeration of possible argument types.
For now "Quoted" and "Unquoted" remain the only types.
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.
Since commit ad502502 (cmMakefile: Track configured files so we can
regenerate them, 2013-06-18) cmMakefile::ConfigureFile records the
configured file as an output file generated by CMake. The intention is
that for make and ninja we can re-run CMake when one of the files it
generates goes missing. However, files configured temporarily in
CMakeTmp directories by Check* modules do not live past the CMake
invocation.
Teach cmMakefile::ConfigureFile to skip tracking files with "CMakeTmp"
in their path, just like cmCoreTryCompile::TryCompileCode does to
avoid adding dependencies on temporary source files. In the future
we will need a more general filter to avoid recording as CMake
outputs any files that do not exist at the end of generation.
It accepted an optional argument to test for equality, but no way
to get the linker language of a particular target.
TARGET_PROPERTY provides this flexibility and STREQUAL provides
the necessary API for equality test.
Extend the CompileDefinitions test to cover accessing the
property of another target.
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.
Currently when a configured file is removed from the build directory,
running the build command will not regenerate the file. Now detect
this and will rerun cmake properly when a user issues the build
command.
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 ...)
ba48e63 Generate config-specific interface link libraries propeties.
deb51a7 Remove unused forward declarations.
9712362 Don't allow utility or global targets in the LINKED expression.
faa927e Make sure INTERFACE properties work with OBJECT libraries.
510fdcb Whitelist target types in target_{include_directories,compile_definitions}
4de7178 Ensure that the build interface includes have been added.
df74bc3 Only append build interface include dirs to particular targets.
d4e5c67 Don't keep track of content determined by target property values.
1fb545a Move a special case for PIC from the genex to the cmTarget code.
57175d5 Only use early evaluation termination for transitive properties.
4cf161a Fix determination of evaluating link libraries.
3a298c0 Fix generation of COMPILE_DEFINITIONS in DependInfo.cmake.
655e98b Ensure type specific compatible interface properties do not intersect.
46e2896 The COMPATIBLE_INTERFACE does not affect the target it is set on.
5f926a5 Test printing origin of include dirs from tll().
7c0ec75 De-duplicate validation of genex target names.
...
Reject the option by default. It will be implemented on a per-generator
basis. Pass the setting into try_compile project generation. Add cache
entry CMAKE_GENERATOR_TOOLSET and associated variable documentation to
hold the value persistently.
Add a RunCMake.GeneratorToolset test to cover basic "-T" option cases.
Verify that CMAKE_GENERATOR_TOOLSET is empty without -T, that -T is
rejected when the generator doesn't support it, and that two -T options
are always rejected.
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.
Since commit e1409ac5 (Support building shared libraries or modules
without soname, 2012-04-22) CMake crashes on the code
add_library(foo SHARED foo.nolang)
because the logic to lookup the language's soname flag was moved from
cmTarget::GetLibraryNames to cmMakefile::GetSONameFlag without its check
for a NULL language. Restore the check for NULL.
Add RunCMake.Languages test to cover language error cases like this one.
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.
Add cmGlobalGenerator::GenerateRuleFile to compute a generator-specific
rule file location. This will allow specific generators to override the
location of .rule files without changing the behavior of other
generators.
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.
Commit 328c0f65 (Simplify cmVisualStudio10TargetGenerator source
classification, 2012-03-19) introduced the first use of source
classification from cmGeneratorTarget (which originated as Makefile
generator logic) in a Visual Studio generator for handling of header
files. Fix classification of header files to match known header
extensions instead of only the HEADER_FILE_ONLY property. Make it
consistent with the "Header Files" source group.
This library type can compile sources to object files but does not link
or archive them. It will be useful to reference from executable and
normal library targets for direct inclusion of object files in them.
Diagnose and reject the following as errors:
* An OBJECT library may not be referenced in target_link_libraries.
* An OBJECT library may contain only compiling sources and supporting
headers and custom commands. Other source types that are not normally
ignored are not allowed.
* An OBJECT library may not have PRE_BUILD, PRE_LINK, or POST_BUILD
commands.
* An OBJECT library may not be installed, exported, or imported.
Some of these cases may be supported in the future but are not for now.
Teach the VS generator that OBJECT_LIBRARY targets are "linkable" just
like STATIC_LIBRARY targets for the LinkLibraryDependencies behavior.
Stephen Kelly
Brad King
Robert Maynard
Nicolas Despres
Andreas Mohr
Yury G. Kudryashov
Petr Kmoch
Peter Kümmel
David Cole
Brian Helba
Modestas Vainius