Commit 7a18dd8e (Add searching of variables, 2003-03-07) added method
cmCursesMainForm::JumpToCacheEntry to search for cache entries whose
names match a given search string. The method also had a useless
argument "int idx" probably left from earlier development iterations and
hard-coded in all calls to the value '-1'. The method compared this
argument to the "NumberOfVisibleEntries" member which at the time was of
type "int" also.
Commit ff1f8d0b (Fix or cast more integer conversions in cmake,
2010-06-29) changed the type of "NumberOfVisibleEntries" to size_t to
fix other integer conversion warnings. An unsigned type makes sense
given the purpose of the member. However, this caused the '-1' signed
value to be converted to a large unsigned value in the above-mentioned
comparison, leading to incorrect behavior.
Fix the problem by removing the useless argument and the comparison.
eccc7d5 Merge branch 'allow_upper_case_cpp_and_others' into resolve/fix_target_name_with_dot_vs10/allow_upper_case_cpp_and_others
ed37fc3 VS2010: Set IntDir for utility and global targets.
e79e412 VS2010: Honor PROJECT_LABEL target property (#10611)
530ade6 Fix targets with . in the name for VS 10 IDE.
The new first arg in the test is the critical one
to prove that the new NMake specific code works.
The additional colons in the middle of the arg
stream work fine everywhere else, but not on
dash1.kitware with Visual Studio 7.1. Just avoid
the failure for now by removing the unnecessary
new args from the test.
VS2010 uses IntDir as the location for writing log files for
what happens during custom build steps. With no IntDir settings,
all ExternalProject usage within the same CMakeLists.txt file
would result in multiple utility targets all trying to use the
same custom build log files.
With parallel builds, they would try to use them simultaneously
and result in file access errors, preventing the builds from
completing successfully.
Now each utility target has its own IntDir setting, and so, its
own custom build rule log files.
The nightly dashboard showed that the following
platforms had difficulties dealing with "bin dir"
and/or "check command line" as directory and
file names:
AIX
Borland 5.5, 5.6 and 5.8
IRIX
NMake 6.0
OpenBSD
VS 7.1
Watcom
Re-visit later, after the release, to use spaces
in the bin dir and in the target name where possible.
The solution seems hackish, but it works: for
NMake only, prepend a no-op command before each
real command that begins with ".
This is really a work-around for an NMake problem.
When a command begins with ", nmake truncates the
first argument to the command after the first :
in that arg. It has a parsing problem.
Workaround..., hackish..., but it should solve
the issue for #9963 and its related friends.
Also, modify the CustomCommand test to replicate
the problem reported in issue #9963. Before the
NMake specific code change, the test failed.
Now, it passes. Ahhhhhh.
The SetError method automatically starts the message with the name of
the command. Fix up calls to it so that we get "file DOWNLOAD..."
instead of "file FILE(DOWNLOAD ...". Also reduce length of long lines
containing these calls.
CUDA 3.2 on Windows systems changed the layout of the library paths. This adds the extra
directories needed to locate the new files.
I also explicitly disable emulation mode for CUDA 3.1+. This feature was deprecated in
3.0 and ultimately removed in 3.1. The script errors out if CUDA_BUILD_EMULATION is
turned on. I didn't want to ignore emulation mode (even with a warning - which most
people may not even see) and have users confused as to why it wasn't working.
Since commit bc43b0f2 (Do not link library dependencies in VS solutions,
2009-10-20) CMake disables for VS >= 8 linking of a target to libraries
that happen to be listed as solution-level dependencies. Therefore we
can list the direct dependencies of each target in the solution file and
let VS handle transitive dependencies automatically.
Dereferencing a 0-pointer is undefined behavior, not a deterministic
crash. Use a 1-pointer instead. This also avoids a warning by Clang
about the undefined behavior.
The default value for CMAKE_INSTALL_PREFIX should be
based on what architecture the built targets are, not
what architecture CMake itself is.
This fix merely guesses better what the built targets
architecture is. It still may guess incorrectly in some
cases. For those cases, it will have to be up to build
scripts and developers on projects to pass in a correct
value for CMAKE_INSTALL_PREFIX with -D on the command line
or via 'force cache value' logic in CMakeLists.txt files.
Brad King
KWSys Robot
David Cole
Bill Hoffman
Marcel Loose
James Bigler