The __aarch64__ defines Aarch64, while __AARCH64EB__ defines bigendian
and __AARCH64EL__ little endian. Only little endian tested, no big
endian toolchain exists yet.
Signed-off-by: Riku Voipio <riku.voipio@linaro.org>
The KWSys "EncodeExecutable" and "ProcessFwd9x" executables were dropped
from KWSys along with Win9x Process support. Drop references from the
rest of the CMake build rules.
Extract upstream KWSys using the following shell commands.
$ git archive --prefix=upstream-kwsys/ 933eb822 | tar x
$ git shortlog --no-merges --abbrev=8 --format='%h %s' 3b17de34..933eb822
Brad King (2):
fea37696 Process: Remove support for Windows 98
01e15c22 Remove KWSys Registry
Rolf Eike Beer (7):
f376ec32 SystemInformation: fix typos
bfee5174 SystemInformation: sum up all caches found in /proc/cpuinfo
5690d711 SystemInformation: fix value extraction from /proc/cpuinfo
36295981 SystemInformation: PA-RISC chips are from HP
72e9d02e SystemInformation: try harder to find a useful processor name
b39de34c SystemInformation: try harder to find the CPU family
933eb822 SystemInformation: extract CPU stepping information from /proc/cpuinfo, too
Sean McBride (2):
5e17bfde Process: Dereference NULL++ instead of NULL to force crash
86a78cb7 SystemTools: Add check for empty strings to prevent integer underflow
Change-Id: Id7194f434fe67be81e6ee9e96d705010a1171a06
Note it is still possible for CTest to start more than the number of
processes specified by PARALLEL_LEVEL, but this prevents the number of
tests to start from being unbounded because of overflow.
Previously we hard-coded a list of implicit framework directories but
did not account for CMAKE_OSX_SYSROOT or for changes to the list across
OS X versions. Instead we should automatically detect the framework
directories for the active toolchain.
The parent commit added the "-Wl,-v" option to ask "ld" to print its
implicit directories. It displays a block such as:
Framework search paths:
/...
Parse this block to extract the list of framework directories.
Detection may fail on toolchains that do not list their framework
directories, such as older OS X linkers. Always treat the paths
<sdk>/Library/Frameworks
<sdk>/System/Library/Frameworks
<sdk>/Network/Library/Frameworks # Older OS X only
/System/Library/Frameworks
as implicit. Note that /System/Library/Frameworks should always be
considered implicit so that frameworks CMake finds there will not
override the SDK copies.
We detect the implicit link directories for the toolchain by adding a
flag to get verbose output from the compiler front-end while linking the
ABI detection binary. Newer OS X toolchains based on Clang do not add
the implicit link directories with -L options to their internal
invocation of "ld". Instead they use a linker that comes with the
toolchain and is already configured with the proper directories.
Add the "-Wl,-v" option to ask "ld" to print its implicit directories.
It displays them in a block such as:
Library search paths:
/...
Parse this block to extract the implicit link directories.
While at it, remove the checks introduced by commit efaf335b (Skip
implicit link information on Xcode, 2009-07-23) and commit 5195a664
(Skip implicit link info for multiple OS X archs, 2009-09-22). Discard
the non-system link directories added by Xcode. Discard all detected
implicit libraries in the multi-architecture case but keep the
directories. The directories are still useful without the libraries
just to suppress addition of explicit -L options for them.
Refactoring in commit 8d674e78 (Ninja: move -LIBPATH behind -link
option, 2012-09-26) accidentally added code that overwrites the
framework search path flags on each iteration instead of appending.
Change '=' to '+=' to fix it. This affects Makefile and Ninja
generators.
Extend documentation for CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES to
explain how it is used by CMake and how it can be influenced by
environment variables.
Inspired-by: Alex Neundorf <neundorf@kde.org>
f0d9385 Makefile: Use modern link information for framework search paths
2bc22bd Xcode: Add frameworks search paths from link dependeny closure (#13397)
Use cmComputeLinkInformation::GetFrameworkPaths to get the list of
framework paths needed by the linker. Drop the now unused framework
information from the old-style cmTarget link dependency analysis.
This should finally fix#13667 and #13762.
Instead of adding special handling to guess whether implicit include dirs
may have been removed, simply make it possible to query the include dirs
without removing the implicit ones.
Alex
The Xcode generator produces FRAMEWORK_SEARCH_PATHS from:
(1) Include directories of the form /path/to/Foo.framework become
-F/path/to so '#include <Foo/H>' can find H in the framework.
(2) Linked frameworks of the form /path/to/Foo.framework become
-F/path/to -framework Foo so the linker can find the framework.
Originally commit 82bb6fae (add framework support to FIND_FILE,
2005-12-27) added these and used the (then current) old-style link
dependency analysis results to get the frameworks. Later a second
setting was added by commit 2ed6191f (add initial xcode framework stuff,
2007-05-08) to transform -F/path/to linker options produced by the old
link line generation into entries appended to FRAMEWORK_SEARCH_PATHS.
Then commit 96fd5909 (Implement linking with paths to library files,
2008-01-22) updated the second setting to directly use the results of
full modern link dependency analysis, but forgot to remove the use of
old-style link results from the original setting location.
The two settings worked together for a while, with the second one
appending to the first. Then commit f33a27ab (Generate native Xcode 3.0
and 3.1 projects, 2009-06-29) changed the internal representation format
produced by the first setting but did not update the second setting to
append to the new representation. As a result, if the first setting
added any paths (usually via the old-style link analysis) then the
second setting containing the modern link analysis results would not be
applied at all.
Fix this by removing use of the old-style link analysis results.
Replace it using the modern link dependencies and remove the second
setting altogether. Now all values for FRAMEWORK_SEARCH_PATHS are
collected in one place so no special append logic is needed.
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.
CONFIGURE_PACKAGE_CONFIG_FILE() now additionally generates
"Any changes to this file will be overwritten by the next CMake run
The input file was FooConfig.cmake.in"
into the configured file.
Alex
Kitware Robot
Stephen Kelly
Brad King
Riku Voipio
David Cole
Casey Goodlett
Alex Neundorf