Use a separate variable to pass to the BUILD_COMMAND call
and then use set(CACHE) to transfer that to MAKECOMMAND.
That way, if MAKECOMMAND is in the cache already, it is
left untouched. Fixes regression introduced in commit
0b38bb4c with the fix for bug #2336.
Thanks to Evgeniy P for the patch.
a798bb7 Avoid CustomCommand test failure on VS71 (#9963)
9b4ab06 Avoid CustomCommand test failure on VS71 (#9963)
9d2e648 No extra spaces in CustomCommand test (#9963)
269a4b8 Enable calling commands with : in argv[1] (#9963)
4a67481 Update release scripts.
7d148d8 Fix the name of the variable being tested.
297be5b add next as an orgin based branch, and not a tag.
187976b Fix release scripts to be able to build releases from tags.
The idea is that we can make sure that CMake is staying backwards
compatible by testing projects against CMake as the changes are made
in CMake. Because these tests will take a long time to run, they
will not be enabled by default. Instead, they will be enabled by
putting a cache variable into CMake.
OK, on windows 7 after we untar some files,
sometimes we can not rename the directory after
the untar is done. This breaks the external project
untar and rename code. So, by default we will wait
1/10th of a second after the untar. If CMAKE_UNTAR_DELAY
is set in the env, its value will be used instead of 100.
Test still failing on dash1.kitware. Give up on testing
the new arg on MSVC71. Test it with newer nmakes instead.
All other dashboards are fine with -DPATH=c:/posix/path
as the first arg, so keep it except when MSVC71 is true.
With CMAKE_OSX_ARCHITECTURE settings such as $(ARCHS_STANDARD_32BIT),
the space inserted by the for loop would confuse Xcode if quoted. In
this particular example, what would be output would be:
ARCHS = "$(ARCHS_STANDARD_32BIT) ";
The Xcode UI does not recognize this as the built-in "Standards 32-bit"
architecture setting unless the space is removed.
Parse compiler flags like "-fmessage-length=0 -fstack-protector
-funwind-tables -fasynchronous-unwind-tables -fno-strict-aliasing" from
the output of "mpicc -show". We already handle preprocessor definition
arguments like -DUSE_STDARG. Honor '-f' flags too.
Add Boost_REALPATH option for people packaging Boost with their app:
Boost_REALPATH Resolves symbolic links for discovered boost libraries
to assist with packaging. For example, instead of
Boost_SYSTEM_LIBRARY_RELEASE being resolved to
"/usr/lib/libboost_system.so" it would be
"/usr/lib/libboost_system.so.1.42.0" instead.
This does not affect linking and should not be
enabled unless the user needs this information.
* Add a warning if the user sets Boost_ROOT which is not correct
* Clarify directions to the user for viewing debugging messages
* Move the CMAKE_FIND_LIBRARY_SUFFIXES tweak outside of a for loop
* Fixed issue 11204: FindBoost.cmake had trouble discovering libraries
when both -sgd and -gd libraries were available by adding a new option
Boost_USE_STATIC_RUNTIME.
Backwards compatibility of searching for first -gd and then -sgd on
WIN32 is maintained unless the user sets Boost_COMPAT_STATIC_RUNTIME to
false (or they have set Boost_USE_STATIC_RUNTIME).
* Fixed issue 8529: FindBoost was unable to detect boost libraries compiled against
STLport, by reworking the way the Boost ABI tag is calculated. There are additional
ABI tag options available now as well.
* Boost_DEBUG now reports the full list of filenames being searched for when
find_library is called.
Use a combination of response files and the archiver to support long
object file lists that do not fit in the Windows command-line length
limit. This can work only with GCC >= 4 because the MinGW GCC 3.x
front-ends do not support response-file syntax.
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.