| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Closes: #18396
|
|
|
|
| |
Issue: #17870
|
|
|
|
|
|
|
|
|
|
|
|
| |
-- Detect GHS compiler and version
Detect ARCHITECTURE_ID for PPC / ARM / 86 targets
Detect PLATFORM_ID for Integrity and Integrity178 platforms
Using defines specified in the documents for the compilers: 201416 PPC / 201754 ARM / 201714 86
-- Fallback C/CXX compiler ID to GHS if not otherwise detected and using GHS MULTI generator
Works around issue with some GHS compilers not setting __ghs__ compiler define
-- Tweak Compiler ID checking so major id of 002017 is not replaced with 217
-- Prefer try_compile() library targets when testing for working GHS compilers
-- Avoid CMake errors if reading past end of file for checking if file is PE executable
|
|
|
|
|
|
|
| |
If `CMAKE_XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY` is set then propagate
it to the compiler id test project too.
Fixes: #18292
|
|
|
|
|
|
|
|
|
| |
Xcode 10 no longer populates `CURRENT_ARCH` with the current
architecture in shell scripts and instead uses `undefined_arch`.
Instead we must use `ARCHS`. It lists all architectures separated by
spaces.
Fixes: #18085
|
|
|
|
|
|
|
|
| |
Add new `version=` parameter in the toolset setting to select the
version. Add variable `CMAKE_VS_PLATFORM_TOOLSET_VERSION` to hold the
version, if one is set (blank indicates default).
Fixes: #17549
|
|
|
|
| |
Closes #16839
|
| |
|
|
|
|
|
|
|
| |
During compiler identification, extract the Xcode `CURRENT_ARCH` value
and save it for later use by the Xcode generator in an internal compiler
information variable. This will be useful to know the locations of
object files when only one architecture is built.
|
| |
|
|
|
|
|
|
| |
Make the `ClCompile` element name and `PostBuildEvent/Command` value
configurable. Move the current content into default values for the
corresponding variables.
|
|
|
|
|
|
| |
The CSharp compiler for VS 2017 has moved from `MSBuildTools` to
`RoslynTargets`. Account for both locations giving priority to the
`MSBuildTools` location.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Visual Studio provides toolchains that are themselves built for 32-bit
or 64-bit host architectures. By default it uses the 32-bit tools, but
it can be told to prefer the 64-bit tools on 64-bit hosts. Extend the
`CMAKE_GENERATOR_TOOLSET` specification to provide a way to request
use of the 64-bit host tools.
Closes: #15622
|
|
|
|
|
|
| |
The `.pbxproj` file must now specify a `SWIFT_VERSION` value.
Set it to the legacy value of "2.3" for now. Later this can
be made configurable (e.g. to "3.0").
|
|
|
|
|
|
| |
This generator has been deprecated since CMake 3.3. Remove it.
Update documentation, modules, and tests to drop content specific
to this generator.
|
|
|
|
|
|
|
|
|
| |
Teach the VS 2015 generator to produce a WindowsTargetPlatformVersion
value. Use the CMAKE_SYSTEM_VERSION to specify the version and if not
set choose a default based on available SDKs. Activate this behavior
when targeting Windows 10.
Co-Author: Brad King <brad.king@kitware.com>
|
| |
|
|
|
|
|
|
|
| |
Allow the `Swift` language to be enabled with the Xcode generator for
Xcode >= 6.1. Reject it on other generators and with older Xcode
versions. Since Apple is the only vendor implementing the language
right now, the compiler id can be just `Apple`.
|
|
|
|
|
|
| |
Teach the Xcode generator that ONLY_ACTIVE_ARCH=YES means to use ARCHS,
and that the default of ONLY_ACTIVE_ARCH=NO means to use NATIVE_ARCH and
ignore ARCHS. In the latter case there is no reason to generate ARCHS.
|
|
|
|
|
|
|
|
| |
The approach in commit v3.1.0-rc1~1^2 (Xcode: Fix compiler id detection
when code signing is required, 2014-10-22) still requires a code signing
key when targeting a real device. Instead set CODE_SIGNING_REQUIRED to
"NO" to tell Xcode not to sign at all. Drop the corresponding setting
of the code signing identity.
|
|
|
|
|
|
|
|
|
|
| |
The iOS product type 'com.apple.package-type.bundle.unit-test' requires
code signing on Xcode 6. Other iOS target types do too. Until CMake
learns to add the CODE_SIGN_IDENTITY build attribute itself, toolchain
files can set CMAKE_XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY to tell the Xcode
generator to add the attribute. Teach CMakeDetermineCompilerId to
recognize this variable and add the CODE_SIGN_IDENTITY build attribute
to the compiler id project.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since commit 0cce556b (Xcode: Use sysroot and deployment target to
identify compiler, 2014-04-29) our compiler id detection project uses
the target platform SDK in case Xcode selects a different compiler based
on it. Now the compiler id project actually compiles with the target
compiler and SDK when cross-compiling.
The iOS tools do not support the 'com.apple.product-type.tool' product
type we use in our compiler id detection project. When targeting
iPhone, use product type 'com.apple.product-type.bundle.unit-test'
instead.
|
|
|
|
|
|
|
|
|
|
| |
Teach CMakeDetermineCompilerId to recognize the Tegra-Android platform
and generate a test project for Nsight Tegra tools. Locate the full
path to CMAKE_<LANG>_COMPILER by computing it within the test project
build environment.
Also teach CMakeFindBinUtils that this variant of the Visual Studio
generator uses UNIX-like instead of MS-like archiving and linking tools.
|
|
|
|
|
|
|
|
|
| |
Add WindowsSDKDesktopARMSupport to the compiler id .vcxproj to
avoid 'error MSB8022: Compiling Desktop applications for the ARM
platform is not supported.' from VS.
Inspired-by: Minmin Gong <minmin.gong@gmail.com>
Inspired-by: Gilles Khouzam <gillesk@microsoft.com>
|
|
|
|
|
|
|
|
|
| |
When CMAKE_SYSTEM_NAME is set to target one of these, add
ApplicationType and ApplicationTypeRevision elements to the .vcxproj
file used to identify the compiler so that the WindowsPhone or
WindowsStore toolchains can work.
Co-Author: Brad King <brad.king@kitware.com>
|
|
|
|
|
|
|
|
| |
Use CMAKE_OSX_SYSROOT and CMAKE_OSX_DEPLOYMENT_TARGET to set the Xcode
SDKROOT and MACOSX_DEPLOYMENT_TARGET build settings. This is necessary
because some versions of Xcode select a different compiler based on
these settings. We need to make sure the compiler identified during
language initialization matches what will be used for the actual build.
|
|
|
|
|
|
| |
Teach CMakeDetermineCompilerId to use a .vfproj project file to
build the Fortran compiler id source file under the Visual Studio
generators.
|
|
|
|
|
|
|
|
| |
Since we do not need the information about the target architecture
we can use the PlatformName only to specify the this information.
This also removes setting of the MSVC_*_ARCHITECTURE_ID variable
which is not required, because this variable gets set by the
compiler detection code in CMAKE_DETERMINE_COMPILER_ID_CHECK().
|
|
|
|
|
|
|
| |
The Microsoft linker is intelligent enough to detect the target
machine type depending on the input files. This allows us to
get the target architecture from the compiler instead of
maintaining the mapping to the platform name.
|
|
|
|
|
| |
id_machine6 is never set to an other value than x86. So it is
safe to remove the replacements with "x86" directly.
|
|
|
|
|
| |
Replace use of lastKnownFileType with explicitFileType to insist
that Xcode treat the file as we ask.
|
|
|
|
|
| |
Implement generator toolset selection (cmake -T) for Xcode > 2.0 by
adding the GCC_VERSION build setting to project files.
|
|
|
|
|
| |
Some Windows CE linkers want to link against LIBC.lib, but can not
find them. Since they are not required we can simply ignore it.
|
|
|
|
|
| |
Set the entry point to mainACRTStartup to make sure that main()
can be found when linking the application to check the compiler.
|
|
|
|
| |
Some WinCE linker only work when the subsystem is set to WINDOWSCE.
|
|
|
|
|
|
| |
Add a dummy mainCRTStartup() function, since the linker searches for
it instead of main() and set the CMAKE_SYSTEM_* variables depending
on the MSVC_C_ARCHITECTURE_ID and CMAKE_VS_WINCE_VERSION variables.
|
|
|
|
|
|
| |
If the TargetMachine isn't defined the linker will choose
the correct target depending on the input file. This helps
us later with additional compiler platforms for WinCE.
|
|
|
|
|
|
|
| |
Configure a hand-generated Visual Studio project to build the compiler id
source file since we cannot run the compiler command-line tool directly.
Add a post-build command to print out the full path to the compiler tool.
Parse the full path to the compiler tool from the build output.
|
|
Configure a hand-generated Xcode project to build the compiler id source
file since we cannot run the compiler command-line tool directly. Add a
post-build shell script phase to print out the compiler toolset build
setting. Run xcodebuild to compile the identification binary. Parse
the full path to the compiler tool from the xcodebuild output.
|