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.
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.
Factor out reading of CMAKE_CONFIGURATION_TYPES and CMAKE_BUILD_TYPE
into cmMakefile::GetConfigurations. Read the former only in
multi-config generators.
7944e4e Allow testing of .CPP on WIN32 as it is a case insensitive OS and should work.
ba0a890 Only test for .CPP on Microsoft compilers which will handle .CPP as c++.
d26cd46 Only use .CPP .CXX and .C++ do not work by default with g+++.
ced61f5 Let CMake recognize .CPP .CXX and .C++ as c++ files.
ede24f8 ENH #8993: FindwxWidgets add support for wx-config custom options.
3dbeeb7 BUG #8184: Fixed FindwxWidgets wrong order of default libs for MinGW.
f46712e BUG #11123: Generic include dir should come after config specific one.
6cb14eb STYLE: Clarified/Fixed documentation of UsewxWidgets.
36c15a2 BUG #10658: FindwxWidgets USE_FILE should not include .cmake extension.