Since commit v3.4.0-rc1~5^2~1 (VS: Add support for selecting the Windows
10 SDK, 2015-09-30) the VS 2015 generator requires a Windows 10 SDK to
be available when CMAKE_SYSTEM_VERSION specifies Windows 10 (e.g. when
building on a Windows 10 host). Howewver, it is possible to install VS
2015 without any Windows 10 SDK. Instead of failing with an error
message about the lack of a Windows 10 SDK, simply tolerate this case
and use the default Windows 8.1 SDK. Since building for Windows Store
still requires the SDK, retain the diagnostic in that case.
In commit v3.4.0-rc1~5^2~1 (VS: Add support for selecting the Windows 10
SDK, 2015-09-30) we added Windows 10 SDK selection choosing the most
recent SDK that is not newer than the target version. This is backward
because it should be up to the application code to not use APIs newer
than the target version. It is up to the build system to provide a SDK
that has at least the APIs expected to be available for the target
version. Furthermore, since the default target version is the host
version of Windows, the old approach breaks when the only SDK available
is for a newer version of Windows.
Fix this by always selecting a Windows 10 SDK if one exists. Use the
SDK for the exact version if is available. Otherwise use the latest
version of the SDK available because that will have at least the APIs
expected for the target version.
Add necessary bits to support the NIOS2 little-endian CPU.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Ley Foon Tan <lftan@altera.com>
Cc: Thomas Chou <thomas@wytron.com.tw>
Cc: Walter Goossens <waltergoossens@home.nl>
Since commit v3.1.0-rc1~110^2 (Tolerate symlinks during RPATH ordering,
2014-09-09) we call realpath() for every directory ordering constraint
check. On some platforms/filesystems this is slow, so memoize the
result of the call for each directory.
We enforce policy push/pop balance around any scope that pushes/pops a
snapshot. Therefore a snapshot may never reference entries of
PolicyStack that were created in nested scopes. Free storage of
short-lived policy stack entries when they are popped.
Add a method to increment an iterator (follow the "up" pointer) to the
previous level in the stack of scopes and free storage of the top of the
stack if possible. This will allow short-lived scopes to be created and
destroyed by matching Push/Pop pairs without accumulating storage.
Logically the method pushes a nested scope on top of a given scope
because the "up" pointer sequence forms a stack independent of any
other branches of the tree.
Everywhere we use cmMakefile::ScopePushPop to manage variable scopes
also expects policy scopes to be balanced. There is no place that we
use cmMakefile::PolicyPushPop without also using ScopePushPop. Relieve
PolicyPushPop of responsibility for policy scope balance checks by
moving it to ScopePushPop.
The PolicyPushPop constructor arguments and Quiet method were used to
pass non-default arguments to PushPolicy and PopSnapshot, but no clients
use them anymore.
The `PopPolicyBarrier` method is actually responsible for closing any
scope opened by creating a snapshot. Rename it to `PopSnapshot` and add
a comment explaining the purpose of the poilcy-scope-specific part of
the method.
Since commit v3.4.0-rc1~179^2~1 (cmState: Add a VariableScope snapshot
type, 2015-08-23) the snapshot stack may have a VariableScopeType entry.
Skip over these when constructing the call stack, just as we do for
policy scopes. Otherwise we report the command causing the variable
scope to be entered twice (e.g. find_package while loading a package
version file).
In commit v3.4.0-rc1~18^2 (Disable shared library support when compiler
links statically, 2015-09-30) we tried to detect when the compiler is
not capable of linking shared libraries (possibly due to flags in use).
However, the approach is not robust against flags like `-nostdlib`.
Revert it for now pending another solution to the original problem.
This fixes a bug where 64 bit builds with /bigobj incorrectly determined
that the object files were not 64 bit. This manifested itself with
printf type functions showing up as undefined because the leading
underscore was being removed and should not be removed.
Prior to commit v3.4.0-rc1~71^2 (Project: Determine default language
dialect for the compiler, 2015-09-15) we always guessed the default
language standard dialect based on the compiler version. This was not
reliable so that commit switched to computing the default language
standard dialect while detecting the compiler id.
When a toolchain file uses CMakeForceCompiler to set the compiler id
then the detection does not occur. Therefore commit v3.4.0-rc1~54^2
(Project: Don't require computed default dialect if compiler was forced,
2015-09-22) made the lack of detection an error only if the compiler was
not forced. However, this means that projects using CMakeForceCompiler
no longer even get the guess that we had before so <LANG>_COMPILER does
not work.
Due to the sophistication of CMake's compiler detection logic projects
should be ported away from using CMakeForceCompiler. In the meantime,
restore a guess of the default language standard dialect when the
compiler is forced.
Our check of CMAKE_PLATFORM_NO_VERSIONED_SONAME, originally added by
commit v3.1.0-rc1~416^2 (Add basic Android platform module, 2014-06-06),
was dropped accidentally by commit v3.4.0-rc1~250^2~21
(cmGeneratorTarget: Move GetLibraryNames from cmTarget, 2015-08-04).
Restore the check in the new location of the GetLibraryNames method.
In commit v3.4.0-rc1~71^2 (Project: Determine default language dialect
for the compiler, 2015-09-15) we added an "INFO:..." string to the
compiler id detection binary. The value can be optimized out of the
compiler id binary unless we force it to be included by making the
program behavior depend on it at runtime. Add references to the value
as we do for the other info strings already.
Gentoo-Issue: https://bugs.gentoo.org/show_bug.cgi?id=565744
Refactoring in commit v3.4.0-rc1~74^2~1 (MSVC: Rewrite manifest file
handling with Makefile and Ninja, 2015-09-15) broke handling of this
option. Fix it and add a test case.
We already recognize the Cray Fortran compiler id. Extract the version
number using the same predefined macros we already use for Cray C and
C++ compilers.
The moved-from location checks for the existence of whether certain
generators are needed for any target in a loop, rather than whether
the current target has an install rule.
This was introduced in commit v3.4.0-rc1~275^2~3 (cmInstallCommand: Move
the SetHaveInstallRule invocation., 2015-07-28). Move the
SetHaveInstallRule call to a more-obvious place where the
cmInstallTargetGenerator is constructed.
