In CMake Policy documentation we specify the default behavior for the
current version of CMake. This commit fixes that version by reporting
the full version number instead of just major and minor.
- Finished updating and formatting documentation.
- Added CUDA_PROPAGATE_HOST_FLAGS (Default ON) that can disable the C flag
propagation to the host compiler.
_ Changed the output directory for support files from
${CMAKE_CURRENT_BINARY_DIR} to ${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles. This
will hopefully reduce the clutter in the binary directory.
The commit "Fix KWSys SystemTools build on cygwin with -mwin32" tried to
restore the state of the _WIN32 definition that was broken by the commit
"Optimize KWSys SystemTools::FileExists on Windows". It did so for the
case of building with -mwin32 on cygwin, but since including <windows.h>
defines _WIN32, it failed for the case of not using -mwin32.
This commit restores the state of _WIN32 in all cases by undefining it
after including <windows.h> if it was not defined beforehand.
Xcode 1.5 writes helper scripts at the projectDirPath location for
targets that do not set SYMROOT. We now add SYMROOT to custom targets
so that all targets set it. This prevents Xcode 1.5 from touching the
source directory now that we always set projectDirPath.
See issue #8481.
Now only the dependencies for the file where the dependencies actually may
have changed are rescanned, before that this was done for all source files
even if only one source file had changed.
This reduces e.g. on my machine the time for scanning the dependencies
of kdelibs/khtml/ when only one file (khtml_global.cpp) has changed from
around 7.5 seconds to 1.2 seconds.
The tests succeed, it does what I expected it to do on kdelibs, and Brad
also reviewed the patch, so I think it should be ok.
Alex
Commit "Optimize KWSys SystemTools::FileExists on Windows" accidentally
added "#undef _WIN32" when including <windows.h> on cygwin, which breaks
builds using the -mwin32 flag. This commit removes that line and fixes
the real error it was intended to avoid.
Xcode project source file references need to always be relative to the
top of the source tree in order for SCM and debug symbols to work right.
We must even allow the relative paths to cross outside of the top source
or build directories.
For subdirectory project() command Xcode projects we use the source
directory containing the project() command as the top. Relative paths
are generated accordingly for each subproject.
See issue #8481.
In cmLocalGenerator::ConvertToRelativePath we normally convert to
relative path only if the local and remote paths both lie inside the
source tree or both lie inside the build tree. This commit adds an
optional 'force' argument to allow conversion even when this rule is
violated.
Implicit link information contains architecture-specific libraries and
directories. The link information cannot be explicitly specified safely
when CMAKE_OSX_ARCHITECTURES contains more than one architecture.
As a result, we currently cannot support mixed-language C++/Fortran
targets and OS X universal binaries simultaneously. In order to avoid
conflicts for simple C/C++ cases, we now simply skip detection of
implicit link information in this case.
If CMakeDirectoryInformation.cmake is newer than depend.internal the include
directories may have changed, so dependencies need to be scanned again.
Ok by Brad.
Alex
We optimize this method by using the GetFileAttributesExA native Windows
API to check for file existence when possible. For real Windows builds
we always use it. For Cygwin we use cygwin_conv_to_win32_path to get a
native Windows path if possible and otherwise fall back to 'access'.
Cygwin-to-Windows path conversion and cache by Wojciech Migda.
See issue #8826.