The use of "cmake -E touch_nocreate" added in commit v3.2.1~4^2
(Makefile: Fix multiple custom command outputs regression, 2015-03-06)
caused builds to fail when one of the outputs is intentionally not
created. This was fixed by our parent commit by making touch_nocreate
succeed when the file is missing. Add a test case covering it.
For the Watcom WMake generator, check for the SYMBOLIC source file
property separately on each output. The mark is needed on outputs that
are not really created to tell 'wmake' not to complain that it is
missing. The mark is also needed on outputs that are created or 'wmake'
will not consider them out of date when they exist.
Inspired-by: Ben Boeckel <ben.boeckel@kitware.com>
Port most CMakeTestBadCommandLines test cases to RunCMake.CommandLine
and drop the former test. Add validation of expected results, which was
not done by the old test.
6c4781ba Tests: Consolidate, refactor and extend -E tar tests
fd04d873 CTestCoverageCollectGCOV: Write tar files intended for CDash in gnutar format
d2cc5807 cmake: Teach "-E tar" command a "--format=" option
1b0c77a3 FindCUDA: Add specific cuda_language_flag instead of using nvcc.
8313de2d FindCUDA: Allow setting CUDA_SOURCE_PROPERTY_FORMAT for non-.cu files.
Port upstream LibArchive commit "compute string pointers after
concatenation" (2014-09-25) and commit "Move variables to top of
function for non-C99 compilers" (2014-11-15) to our CMake copy.
Otherwise we may compute a pointer to memory that is about to be freed
and then compute a bad size to give to CryptGenRandom.
Inspired-by: Tim Kientzle <kientzle@gmail.com>
I was previously appending to nvcc_flags inside the file loop. This
caused the flag to be appended multiple times which freaks out nvcc.
Now the flag is specifically handled per file.
A previously undocumented feature allowed overriding the format
specified to CUDA_WRAP_SRCS with a source file property called
CUDA_SOURCE_PROPERTY_FORMAT. I added documentation for this feature as
well as added the ability to let nvcc compile any file regardless of
type if this property was found.
In addition, I also fixed a couple of bugs with the calls to
_cuda_get_important_host_flags that weren't garding the arguments with
"" to prevent empty values from causing errors.
ba404938 cmCacheManager: Port consumers to non-iterator API.
f3922a9a Port QtDialog to non-iterator cache API.
3e6a76e4 Port CursesDialog to non-iterator cache API.
9e641567 cmMakefile: Port away from CacheEntry.Initialized.
1e2dbfce cmCacheManager: Add non-iterator-based API.
60a62a91 cmCacheManager: Return a C string from GetValue.
77f2807c cmCacheManager: Rename GetCacheValue to GetInitializedCacheValue.
14973054 Add API for cache loading, deleting and saving to the cmake class.
1f2c12eb cmMakefile: Remove cache version accessors.
97c50a8d cmMakefile: Simplify GetDefinitions implementation.
882f48e5 Link libraries by full path even in implicit directories
318cd370 Help: Add link target for Find Modules section of cmake-developer.7
1535dcd8 Tests: Teach RunCMake to optionally merge command output to stdout
When CMP0003 was first introduced we wanted to link all libraries by
full path. However, some projects had problems on platforms where
find_library would find /usr/lib/libfoo.so when the project really
wanted to link to /usr/lib/<arch>/libfoo.so and had been working by
accident because pre-CMP0003 behavior used -lfoo to link.
We first tried to address that in commit v2.6.0~440 (Teach find_library
to avoid returning library paths in system directories, 2008-01-23) by
returning just "foo" for libraries in implicit link directories. This
caused problems for projects expecting find_library to always return a
full path. We ended up using the solution in commit v2.6.0~366 (...
switch library paths found in implicit link directories to use -l,
2008-01-31). However, the special case for libraries in implicit link
directories has also proven problematic and confusing.
Introduce policy CMP0060 to switch to linking all libraries by full path
even if they are in implicit link directories. Explain in the policy
documentation the factors that led to the original approach and now to
this approach.
If the host flags contain a c++11 flag (at least for gcc), then we can't
automatically propagate to nvcc it using -Xcompiler. This is because
nvcc can't use any C++ only flags. Instead we find this flag and add it
to nvcc's flags (it has a special flag for dealing with c++11 code) and
remove it from the host flags.
Co-Author: Guillermo Marcus <gmarcus@nvidia.com>
Stephen Kelly
Kitware Robot
Brad King
Gerald Combs
Nils Gladitz
Tim Kientzle
James Bigler