At least some versions (e.g. C++ Builder 5) of the bcc32 linker are known to
write temporary files with a constant name to the current directory (e.g.
"turboc.$ln"). (This can be verified by using Process Monitor to watch the
file writes that bcc32 / ilink32 / implib make). This causes problems with
some generators that keep a constant current directory and run concurrent
linkers.
For example, the Ninja generator, by default, always has the current directory
set to the top of the build tree - resulting in conflicts between the linkers
that are simultaneously trying to write to "turboc.$ln". Symptoms include
direct errors regarding the "turboc.$ln" file, or later build steps failing due
to corrupted output from previous links that happened to link "successfully."
This is not a problem for the Borland Makefiles generator which does not
run jobs in parallel. For the Ninja generator, work around this problem
by using a link job pool of size 1.
Move PARTIALLY_RELOCATABLE_WARNING test to the new common CPack test
script structure to have all tests in one place as well as additional
benefit of having some more checks done during test execution.
Otherwise using a "cc -> ccache" or similar symlink as the compiler
causes FindCUDA to select ccache as the host compiler. Update the logic
added by commit v3.1.0-rc1~354^2 (FindCUDA: Fix OSX Clang & no C
language enabled, 2014-06-12) to apply only in the specific case it is
needed.
Create a <LANG>_COMPILER_LAUNCHER target property (initialized by a
CMAKE_<LANG>_COMPILER_LAUNCHER variable) to specify a compiler launcher
tool. This will supersede the CMAKE_<LANG>_COMPILER_ARG1 approach to
using such tools. The old approach set CMAKE_<LANG>_COMPILER to the
launcher tool while the new approach leaves this variable set to the
actual compiler.
Implement this property for Makefile and Ninja generators. It cannot be
implemented for VS or Xcode generators as the IDE build tools offer no
such hooks.
Fix generation of tgt/fast build targets.
Commit 363caa2f (cmLocalGenerator: De-virtualize Configure().,
2015-05-30) moved the computation of HomeRelativeOutputPath from
Configure-time to Generate-time, because it is only used at
Generate-time. However, that commit caused the member for one
local generator to be computed immediately before generating with
that local generator, whereas previously the members of all local
generators were computed before generating any of them.
The HomeRelativeOutputPath is used by the GetRelativeTargetDirectory
method, which is called by the
cmGlobalUnixMakefileGenerator3::WriteConvenienceRules method. That
method is called by the
cmLocalUnixMakefileGenerator3::WriteLocalMakefile method when generating
for the top-most (ie, the first) local generator. At that point,
the HomeRelativeOutputPath is not yet computed.
Fix that by computing the member just before generating anything.
This will eventually be done in the cmLocalUnixMakefileGenerator3
constructor instead, but further refactoring is needed to make
that possible.
The VS >= 10 generators need to parse the .sln file from the build
directory to locate targets in subdirectories. This occurs after we
change the working directory to the build tree. If a relative directory
other than "." was given then we would change to it and also refer to
the .sln file location with it. Fix this by converting the build tree
to a full path always. This will also give a more informative error
message when the directory does not exist.
Make RETURN_VALUE report -1 if the update command failed as the
documentation claims. Also avoid reporting a ctest script-level failure
if the update command fails because we still correctly administered the
update step.
