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.
In commit 236133e7 (Handle targets in the LINK_LIBRARIES of try_compile,
2013-02-09) an error return case was added without closing the file in
progress. Add the missing fclose() call.
Spotted by sevenhill.
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
This allows the ctest_build command's TARGET option to name a target
in a subdirectory and still build properly with msbuild.
Add test case covering use of ctest_build() with such a TARGET.
In cmCTestHandlerCommand::InitialPass call InitializeHandler after setting
the CTest "SourceDirectory" and "BuildDirectory" configuration values
instead of before. This makes the values available to InitializeHandler
methods in subclasses, so also drop the duplicate configuration of those
values from cmCTestConfigureCommand::InitializeHandler.
Add test covering cmGlobalGenerator::GenerateBuildCommand for VS
solutions with MSBuild and building a target defined in a subdirectory
and not part of ALL.
Use cmVisualStudioSlnParser in GenerateBuildCommand() to provide correct
command line for MSBuild even when target project is stored in a
subdirectory.
Create class cmVisualStudioSlnParser as a generic parser for Visual
Studio .sln files. Implement minimum functionality but keep class
extensible. Add tests for the class.
Extend the cmGlobalGenerator::GenerateBuildCommand virtual method
signature with a "projectDir" parameter specifying the top of the
project build tree for which the build command will be generated.
Populate it from call sites in cmGlobalGenerator::Build where a
fully-generated build tree should be available.
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.
Use the suggestion from http://support.microsoft.com/kb/2262855 to escape
semicolons in preprocessor definitions for VS >= 10. Update the
COMPILE_DEFINITIONS documentation disclaimer list of known limitations
accordingly. Update our "Preprocess" test to cover the case.
Suggested-by: Jean-Christophe Fillion-Robin <jchris.fillionr@kitware.com>
Transform the path using ConvertToNinjaPath just as we do for all other
paths. This fixes the OutOfSource test for objects in the ../OutOfBinary
directory by computing the proper full path for the /Fd option.