d118b8b Add IAR to the CMakeDetectC(XX)CompilerID.c(pp).in
d33f406 Add regexps for the IAR toolchain to the vendor list.
22fb73a Add support files for C, C++ and ASM for the IAR toolchain.
f055c99 CPackRPM add /usr/lib64 to the list of builtin to-be-excluded path
bac5772 CPackRPM add mechanism to remove path from generated list of file in RPM spec.
Initialize the CMAKE_CONFIGURATION_TYPES cache entry early during
EnableLanguage like the Xcode generator does. Avoid depending on
the MSVC compiler information module to do it. Otherwise code like
project(MyProj NONE)
sets CMAKE_CONFIGURATION_TYPES late (in GenerateConfigurations), and
to only "Debug" and "Release" instead of the standard set of 4.
Reported-by: Paul Smith <paul@mad-scientist.net>
Since Java is a portable language, if you want to use Java when
cross-compiling, UseJava uses the JVM installed on the host. So in this
case, we must use set CMAKE_JAVA_INCLUDE_FLAG_SEP for the current host.
With
SVN_USERNAME ""
SVN_PASSWORD ""
in an ExternalProject_Add() call, the blank username and password
will be passed to the svn checkout/update step commands.
Without this, when CPACK_NSIS_ENABLE_UNINSTALL_BEFORE_INSTALL is set,
the installer tries to uninstall the old version from the default
installation path for the new version, rather than using the path from
the registry where the old version is installed.
Commit dac78148 (...makes the mingw cross compiler work out of the
box..., 2007-08-02) added to CMAKE_SYSTEM_PROGRAM_PATH and
CMAKE_SYSTEM_LIBRARY_PATH paths like "/bin" and "/lib" with no Windows
drive letter so that cross-compiling to Windows from Linux would search
these paths under CMAKE_FIND_ROOT_PATH. Later commit 2a782880 (...use
CMAKE_SYSTEM_PREFIX_PATH when possible, 2008-01-16) generalized this
approach by instead adding "/" to CMAKE_SYSTEM_PREFIX_PATH.
Both commits assumed that the paths would never match anything on
Windows hosts without a drive letter. However, Windows evaluates these
paths relative to the current working drive letter so find_* commands
may report paths like "/lib/..." when paths like "c:/lib/..." exist on
what happens to be current drive. Such drive-less paths are not
reliable when the working drive changes, so we should not use them.
Fix WindowsPaths.cmake to add '/' to CMAKE_SYSTEM_PREFIX_PATH only when
cross-compiling to Windows from a non-Windows host. This will avoid
searching and finding local paths without a drive letter on Windows.
Set the locale to C while running the compiler for these checks because
we match the resulting warning messages in English only.
Suggested-by: Marco Nolden <m.nolden@dkfz-heidelberg.de>
As of CMake 2.8.8, the INCLUDE_DIRECTORIES() command does
not de-duplicate entries. Failure to do so can lead to an extremely
long and repetitive list of -I entries on the command line.
make CUDA_COMPUTE_BUILD_PATH use a relative path to the current
binary directory instead of the current source directory if the source
file considered is in the current binary directory. This is done to
shorten the paths given to the compiler.
This was using nested if's, now it uses elseif to flatten that. It also removes
one "if" from the general "else" branch that checks for Apple, as that has it's
own branch anyway and can't be true at this point.
Make the CMAKE_HOST_* variables always available in the toolchain file.
They are when the file is included in CMakeDetermineSystem.cmake, and
now also here. For the non-cross-compiling case this does not change
anything at all.
Alex
Use of the mis-spelled variable name 'CMAKE_CROSS_COMPILING' was
introduced by commit 4b793ad1 (FindOpenSSL: find cross-compiled OpenSSL
from MinGW, 2012-07-23). Fix the spelling.
Update the CMAKE_<LANG>_LINK_EXECUTABLE rule variable to invoke the
linker directly instead of through the compiler. We already do this
for DLL linking with CMAKE_<LANG>_CREATE_SHARED_LIBRARY.
This also works around a VS 6 cl bug. While invoking the link tool
internally it fails to correctly quote flags like /pdb:... with spaces
in the value.
The MS tools create two types of PDB files as explained here:
http://msdn.microsoft.com/en-us/library/yd4f8bd1%28v=vs.71%29.aspxhttp://msdn.microsoft.com/en-us/library/yd4f8bd1%28v=vs.80%29.aspxhttp://msdn.microsoft.com/en-us/library/yd4f8bd1%28v=vs.90%29.aspxhttp://msdn.microsoft.com/en-us/library/yd4f8bd1%28v=vs.100%29.aspx
One is created by the compiler (/Fd) and the other by the linker (/pdb).
The two options should not specify the same file. Split them up.
In the VS IDE generators, simply drop ProgramDataBaseFileName to
take the VS default "/Fd$(IntDir)vc$(PlatformToolsetVersion).pdb".
In the Makefile generators, set "/Fd" on the compile line to be
the directory containing object files (with a trailing slash the
compiler will add the "vc$(PlatformToolsetVersion).pdb" filename
automatically). Drop the /Fd option from the exe link command
line and add "/pdb" instead (already done for dll linking).
Update these rules for both MSVC and Intel tools.
Drop support for PDB_OUTPUT_DIRECTORY and PDB_NAME in STATIC
libraries because the generated .pdb files are only from /Fd
and not real linker-generated .pdb files. Update documentation to
clarify that the PDB_* properties are only for linker .pdb files.
This regresses the PDBDirectoryAndName test for STATIC libraries.
Since it is not clear at this time what should be done for STATIC
library .pdb files, comment out the relevant portion of the test
and leave a TODO comment.
This fixes bug #0013609, and is a possible solution to #0012864 as well.
The later will be completely fixed in another way. Both approaches
needs to be implemented because the current one is more automatic.
Inspired-By: Ari
Brad King
Clinton Stimpson
Gregoire Lejeune
Alexander Mohr
Andreas Mohr
Matt McCormick
David Golub
Marcel Loose
Mathias Gaunard
Rolf Eike Beer
Alex Neundorf
Stephen Kelly
Robin Lee
Eric NOULARD