Extract upstream KWSys using the following shell commands.
$ git archive --prefix=upstream-kwsys/ 6fa1c99f | tar x
$ git shortlog --no-merges --abbrev=8 --format='%h %s' 608d6b47..6fa1c99f
Brad King (1):
84827cc1 Process: Avoid argv[0]==NULL from parsing empty command line
Rolf Eike Beer (8):
e041cd66 SystemInformation: factor out QueryMemoryBySysconf()
ea850fa0 SystemInformation: factor out QueryProcessorBySysconf()
57f06d49 SystemInformation: count processors with sysconf() on Solaris
c6057a06 SystemInformation: fix "Multi-character character constant"
5a27bd4f SystemInformation: make IsHyperThreadingSupported() return bool
342c0ad2 SystemInformation: query memory size with sysconf() on Solaris
f0b857c1 SystemInformation: cache result of IsHyperThreadingSupported()
ab0c2a09 SystemInformation: try using assembler with BorlandC
Change-Id: I072371ed35eed892a5ef62a9e9e6cad734e961d9
Don't add generator expressions to variables which are used
for CMP0003, CMP0004, and the old-style _LIB_DEPENDS content. They
will not be evaluated when read anyway and would probably confuse
the code reading them.
This makes it legitimate to use target_link_libraries with generator
expressions as arguments.
Extract upstream KWSys using the following shell commands.
$ git archive --prefix=upstream-kwsys/ 608d6b47 | tar x
$ git shortlog --no-merges --abbrev=8 --format='%h %s' fc60c8b8..608d6b47
Rolf Eike Beer (6):
297758a5 SystemInformation: fix conversion warning
79ef34ef SystemInformation: fix calling kwsysProcess_WaitForData()
f1068caf SystemInformation: speed up copying process data
7dfc27d5 SystemInformation: check CPU vendor and SSE support on OpenBSD
494d9d7a SystemInformation: get stepping code on Intel Macs
608d6b47 SystemInformation: determine processor features on Intel Macs
Change-Id: I7f5bc5b7af2bf7d4e5c1ee291c286add0f17a7d5
77d2646 Allow generator expressions in LINK_INTERFACE_LIBRARIES.
94aeaf7 Split LINK_INTERFACE_LIBRARIES export handling into dedicated method.
a3aedb8 Split the generator expression before extracting targets.
b6036d1 Extract the AddTargetNamespace method.
cb1afbf Don't pass a position when determining if a target name is a literal.
f99196d Add cmGeneratorExpression::Split() API.
In the implementation of "cmake -E cmake_link_script", skip lines from
the input file that are empty or contain only whitespace. Do not try to
run a child with no command line.
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.
Now that we're processing a LINK_INTERFACE_LIBRARIES string, it
can contain targets. Make sure they are extracted for
namespacing purposes.
This needs to be restricted to strings which can actually have
targets named in them. For example, this is not done for
INTERFACE_COMPILE_DEFINITIONS, because even if there is a target
named 'foo', the string 'foo' in that property means that '-Dfoo'
will be set when compiling.
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).
3581b96 Process the INTERFACE_PIC property from linked dependencies
042ecf0 Add API to calculate link-interface-dependent bool properties or error.
bf5ece5 Keep track of properties used to determine linker libraries.
0380f36 FindOpenGL: add Haiku paths
8e9630c FindGLUT: BeOS does not have libXi and libXmu
50bfedf FindLua51: do not try to link libm on BeOS
3d2e6a0 check for Haiku only with __HAIKU__
7a1b961 Haiku no longer defines __BEOS__
ed96d9a bootstrap: use better defaults for Haiku
This allows a dependee to inform a target that it should have its
POSITION_INDEPENDENT_CODE property set to ON, or OFF. The value of
the POSITION_INDEPENDENT_CODE property, if set, must be consistent
with any INTERFACE_POSITION_INDEPENDENT_CODE properties on dependees.
Add a test covering the consistency checks on platforms where they run.
Old GNU compilers do not define __SIZEOF_LONG_LONG__ or
__LONG_LONG_MAX__ but do provide a 64-bit 'long long' type.
Suggested-by: Rolf Eike Beer <eike@sf-mail.de>
This new method checks that the property FOO on a target is consistent
with the INTERFACE_FOO properties of its dependees. If they are not the
consistent, an error is reported. 'Consistent' means that iff the
property is set, it must have the same boolean value as all other
related properties.
This makes
set(CMAKE_BUILD_INTERFACE_INCLUDES ON)
add the equivalent of
set_property(TARGET tgt APPEND PROPERTY
INTERFACE_INCLUDE_DIRECTORIES
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR};${CMAKE_CURRENT_BINARY_DIR}>
)
to every target.
If the headers are in CMAKE_CURRENT_SOURCE_DIR, and the generated headers
are in CMAKE_CURRENT_BINARY_DIR, this is a convenient way to build a target
bar, which depends on foo, just by using target_link_libraries() and adding
the INTERFACE_INCLUDE_DIRECTORIES to the INCLUDE_DIRECTORIES of the target
being linked. There will be more-convenient porcelain API to consume the
property in the future.
This makes it possible to use:
target_link_libraries(foo LINK_INTERFACE_LIBRARIES bar)
where foo is an IMPORTED target. Other tll() signatures are not
allowed.
Previously we kept direct link dependencies in OriginalLinkLibraries.
The property exposes the information in the CMake language through the
get/set_property commands. We preserve the OriginalLinkLibraries value
internally to support old APIs like that for CMP0003's OLD behavior, but
the property is now authoritative. This follows up from commit d5cf644a
(Split link information processing into two steps, 2012-11-01).
This will be used later to populate the link interface properties when
exporting targets, and will later allow use of generator expressions
when linking to libraries with target_link_libraries.
Also make targets depend on the (config-specific) union of dependencies.
CMake now allows linking to dependencies or not depending on the config.
However, generated build systems are not all capable of processing
config-specific dependencies, so the targets depend on the union of
dependencies for all configs.
Yury G. Kudryashov
Brad King
KWSys Robot
Stephen Kelly