* Disable the system include unused variable test in ExportImport when
clang is in MSVC compatible mode.
* Disable CxxDialect testcase when clang is in MSVC compatible mode, as
it doesn't support `typeof`.
* Teach Module.WriteCompilerDetectionHeader to treat clang-cl as MSVC.
* Disable the SystemIncludeDirectories testcase within
IncludeDirectories when clang is in MSVC compatible mode.
* Disable the CMakeOnly.CheckCXXCompilerFlag testcase when clang is in
MSVC compatible mode.
* Treat clang-cl as MSVC in LinkOptions.cmake in the try_run and
try_compile testcases.
These new capabilities enable to manage link directories
Two new properties:
* target properties: LINK_DIRECTORIES and INTERFACE_LINK_DIRECTORIES
One new command
* target_link_directories(): to populate target properties
Fixes: #17215
Previously the command did not allow naming targets on the LHS that
were not created in the calling directory. Lift this restriction to
enable more flexible use by projects.
Targets named on the RHS will need to be looked up during generation in
the scope of the call site rather than the scope of the LHS target.
Introduce an internal syntax in `[INTERFACE_]LINK_LIBRARIES` properties
to specify target names that need to be looked up in a directory other
than that containing the target on which the property is set. Add
minimal documentation of the syntax to help users that encounter it.
Unfortunately CMake previously did allow such calls in the case that
only `INTERFACE` libraries are specified, but those libraries would be
looked up in the target's directory rather than the caller's. Add
policy `CMP0079` to enable the new behavior with new lookup scope in a
compatible way.
Fixes: #17943
This family enable to manage link flags
Three new properties:
* directory property: LINK_OPTIONS
* target properties: LINK_OPTIONS and INTERFACE_LINK_OPTIONS
Two new commands
* add_link_options(): to populate directory property
* target_link_options(): to populate target properties
Fixes: #16543
Run the `clang-format.bash` script to update all our C and C++ code to a
new style defined by `.clang-format`. Use `clang-format` version 6.0.
* If you reached this commit for a line in `git blame`, re-run the blame
operation starting at the parent of this commit to see older history
for the content.
* See the parent commit for instructions to rebase a change across this
style transition commit.
This change introduces an additional property that may be set on a
target to allow additional properties to be exported. Normally only a
limited number of properties are exported.
Additional properties may be exported by simply setting the
`EXPORT_PROPERTIES` property on a target that is exported.
Teach the `install` and `export` commands to support installing and
exporting `OBJECT` libraries without their object files. Transform
them to `INTERFACE` libraries in such cases.
For `install(TARGETS)`, activate this when no destination for the object
files is specified. For `export`, activate this only under Xcode with
multiple architectures when we have no well-defined object file
locations to give to clients.
Teach install() and export() to handle the actual object files.
Disallow this on Xcode with multiple architectures because it
still cannot be cleanly supported there.
Co-Author: Brad King <brad.king@kitware.com>
Run the `Utilities/Scripts/clang-format.bash` script to update
all our C++ code to a new style defined by `.clang-format`.
Use `clang-format` version 3.8.
* If you reached this commit for a line in `git blame`, re-run the blame
operation starting at the parent of this commit to see older history
for the content.
* See the parent commit for instructions to rebase a change across this
style transition commit.
Sort include directives within each block (separated by a blank line) in
lexicographic order (except to prioritize `sys/types.h` first). First
run `clang-format` with the config file:
---
SortIncludes: false
...
Commit the result temporarily. Then run `clang-format` again with:
---
SortIncludes: true
IncludeCategories:
- Regex: 'sys/types.h'
Priority: -1
...
Commit the result temporarily. Start a new branch and cherry-pick the
second commit. Manually resolve conflicts to preserve indentation of
re-ordered includes. This cleans up the include ordering without
changing any other style.
Use the following command to run `clang-format`:
$ git ls-files -z -- \
'*.c' '*.cc' '*.cpp' '*.cxx' '*.h' '*.hh' '*.hpp' '*.hxx' |
egrep -z -v '(Lexer|Parser|ParserHelper)\.' |
egrep -z -v '^Source/cm_sha2' |
egrep -z -v '^Source/(kwsys|CursesDialog/form)/' |
egrep -z -v '^Utilities/(KW|cm).*/' |
egrep -z -v '^Tests/Module/GenerateExportHeader' |
egrep -z -v '^Tests/RunCMake/CommandLine/cmake_depends/test_UTF-16LE.h' |
xargs -0 clang-format -i
This selects source files that do not come from a third-party.
Inspired-by: Daniel Pfeifer <daniel@pfeifer-mail.de>
Commit 899458ab (Tests: Cover NO_SONAME property for SHARED libraries,
2015-08-20) introduced a few new ExportImport tests, and the
check_lib_{no}soname.cmake scripts that parse readelf(1)'s output.
Make the regular expression matching the SONAME line output by readelf
less strict, as the output format varies across implementations: GNU
binutils' readelf is the only one to write each ELF header within
parentheses (which the previous regular expression expected). The new
tests were thus failing when either Fedora's elfutils (eu-readelf) or
elftoolchain's readelf (present on recent FreeBSD versions) were being
used, as they both list the headers without parentheses.
The same issue also affected Tests/Plugin's check_mod_soname.cmake, so
fix that one as well -- the only reason the test was not failing is that
it tested that the regular expression did not match, which was always
the case with a non-binutils readelf.
This property was added by commit v2.8.9~204^2~2 (Support building
shared libraries or modules without soname, 2012-04-22). A test for
using the property on MODULE libraries was added by commit
v2.8.9~204^2~1 (Test NO_SONAME property, 2012-04-23). Add such a test
for SHARED libraries too.
If {ARCHIVE,LIBRARY,RUNTIME}_OUTPUT_DIRECTORY is set with a genex then
do not add the per-config subdirectory on multi-config generators.
This will allow projects to use $<CONFIG> to place the per-config
part of the directory path somewhere other than the end.
The iface_test_bld gets the excludedFromAll include directory with
"-isystem" because it is added indirectly through an imported target.
On AIX with GCC the -isystem flag causes sources to be preprocessed as:
# 3 "/.../excludedFromAll.h" 2 3 4
The flags after the file name are documented here:
https://gcc.gnu.org/onlinedocs/cpp/Preprocessor-Output.html
and the "4" flag says that following content is extern "C". This
causes the excludedFromAll function to be declared as a C symbol
and not mangled for C++, which fails to link later because the
symbol is really provided as C++.
Work around this by setting the NO_SYSTEM_FROM_IMPORTED target property
on iface_test_bld. Somehow iface_test_exp does not end up with -isystem
so we do not need this workaround for that target.
This will allow per-config destinations for targets in EXPORT sets.
Using multiple install(TARGETS) with separate CONFIGURATIONS is
rejected as a target appearing more than once in an export set.
Now instead one can write
install(TARGETS foo EXPORT exp DESTINATION lib/$<CONFIG>)
to get a single logical membership of the target in the export set
while still having a per-config destination.
When install(EXPORT) is given an absolute destination we cannot compute
the install prefix relative to the installed export file location.
Previously we disallowed installation of targets in such exports with a
relative destination, but did not enforce this for target property
values besides the location of the main target file. This could lead to
broken installations when the EXPORT is installed to an absolute path
but usage requirements are specified relative to the install prefix.
Since an EXPORT installed to an absolute destination cannot be relocated
we can just hard-code the value of CMAKE_INSTALL_PREFIX as the base for
relative paths. This will allow absolute install(EXPORT) destinations
to work with relative destinations for targets and usage requirements.
Extend the ExportImport test with a case covering this behavior.
Teach the install(FILES) and install(PROGRAMS) commands to evaluate
generator expressions in the list of files.
Extend the ExportImport test to cover installation cases involving
generator expressions.
Code such as
target_include_directories(foo INTERFACE
$<INSTALL_INTERFACE:include$<FOO>>
)
should be treated as a relative directory, despite the genex, after
the INSTALL_INTERFACE is stripped away.
Previously, this would generate a relative directory on export, which
would be an error on import, so no policy is needed.
Code such as
install(TARGETS ...
INCLUDES DESTINATION $<INSTALL_INTERFACE:include>
)
should behave as if the INSTALL_INTERFACE wrapper were not present.
In code such as
install(TARGETS ...
INCLUDES DESTINATION $<FOO>include
)
the generator expressions are evaluated at generate-time. Delay
determining whether each entry is a relative path until after
the generator expressions are evaluated. Such relative paths
are based relative to the CMAKE_INSTALL_PREFIX.
Export the INCLUDES DESTINATION without appending to the
INTERFACE_INCLUDE_DIRECTORIES of the target itself. That way, a target
can be exported multiple times with different INCLUDES DESTINATION
without unintended cross-pollution of export sets.
3e30d9e TLL: Don't populate old link interface if CMP0022 is NEW.
574fec9 Export: Generate INTERFACE_LINK_LIBRARIES property on targets.
d0a76ea Introduce the INTERFACE_LINK_LIBRARIES property.
ddde61c Introduce the LINK_ONLY generator expression.
5aa9731 GenexEval: Add abstracted access to link interface for a target.
This property is generated only for targets which have recorded
policy CMP0022 as NEW, and a compatibility mode is added to
additionally export the old interfaces in that case too.
If the old interfaces are not exported, the generated export files
require CMake 2.8.12. Because the unit tests use a version which
is not yet called 2.8.12, temporarily require a lower version.
If a non-IMPORTED library is added to the INTERFACE_LINK_LIBRARIES
of a IMPORTED target, the non-IMPORTED target needs to become a
target dependency and link dependency of the consuming target.
This is already the case since commit 30962029 (Make targets depend
on the link interface of their dependees, 2012-12-26), and fixed in
the parent commit, so test that it works.
This allows for example, the buildsystem to use names like 'boost_any'
instead of the overly generic 'any', and still be able to generate
IMPORTED targets called 'boost::any'.
This establishes that linking is used to propagate usage-requirements
between targets in CMake code. The use of the target_link_libraries
command as the API for this is chosen because introducing a new command
would introduce confusion due to multiple commands which differ only in
a subtle way.
The Config and IMPORTED_ variants may also contain generator
expressions.
If 'the implementation is the interface', then the result of
evaluating the expressions at generate time is used to populate
the IMPORTED_LINK_INTERFACE_LIBRARIES property.
1) In the case of non-static libraries, this is fine because the
user still has the option to populate the LINK_INTERFACE_LIBRARIES
with generator expressions if that is what is wanted.
2) In the case of static libraries, this prevents a footgun,
enforcing that the interface and the implementation are really
the same.
Otherwise, the LINK_LIBRARIES could contain a generator
expression which is evaluated with a different context at build
time, and when used as an imported target. That would mean that the
result of evaluating the INTERFACE_LINK_LIBRARIES property for
a static library would not necessarily be the 'link implementation'.
For example:
add_library(libone STATIC libone.cpp)
add_library(libtwo STATIC libtwo.cpp)
add_library(libthree STATIC libthree.cpp)
target_link_libraries(libtwo
$<$<STREQUAL:$<TARGET_PROPERTY:TYPE>,STATIC_LIBRARY>:libone>)
target_link_libraries(libthree libtwo)
If the LINK_LIBRARIES content was simply copied to the
IMPORTED_LINK_INTERFACE_LIBRARIES, then libthree links to libone, but
executables linking to libthree will not link to libone.
3) As the 'implementation is the interface' concept is to be
deprecated in the future anyway, this should be fine.
Make a C executable instead of attempting to make a C++ static
library (and not really succeeding). This was introduced in
commit 894f52f3 (Handle INTERFACE properties transitively for
includes and defines., 2012-09-23).
