Commit d84cbd0f (FindMPI: Parse mpicc flags more carefully, 2010-06-24)
broke parsing of '-L' flags appearing after '-Wl,' by expecting a
preceding space. Update the regular expression to allow '-Wl,-L' too.
Do not hard-code known BlueGene/L MPI libraries. We do not know their
location so the linker cannot find them without the proper -L search
path. The MPI compiler tells us about the libraries anyway, and if it
does not then the user can fix the problem locally by editing the
MPI_EXTRA_LIBRARY cache entry.
Extend the fix from commit 68c7d3e2 (FindMPI: Do not parse -l in middle
of library name, 2010-06-24). Parse -D, -I, -L, and -Wl only with
preceding spaces or at the beginning of the string.
ldd can return "not found" and we need to handle it correctly.
In that case, we extract only the name of the library instead of trying for its full path.
Some zlib.h files have ZLIB_VERSION "1.2.3.3" with 4 numbers instead of 3.
The regex is changed to grab the first 3 numbers.
It was slow because if it failed to find that string near the top of the file,
where it usually is, it would read the entire file.
We parse the output of 'mpicc -shome:link' to look for -l options
specifying libraries. Fix the parsing regex to avoid matching the
string '-l' in the middle of a library name.
Avoid issues with two external projects trying to extract two
separate trees at the same time into the same location. Should
fix the sporadically failing ExternalProject test on the dashboards
for parallel builds.
In version 3.0 of the CUDA toolkit when building code for emulation, you need to link
against a new version of the cuda run time library called cudartemu. This CL adds a check
for the new library and uses it when present and in emulation mode. Note that this
library is not present in previous or subsequent versions of the CUDA toolkit.
Tru64's make(1) resolves relative paths in "include" directives with
respect to the includer. This is inconsistent with all other known make
tools. Note that this make tool treats the path literally so we cannot
use our standard FULL path code which escapes spaces. Instead qualify
the paths with $(CMAKE_BINARY_DIR) to avoid the problem.
See http://public.kitware.com/Bug/view.php?id=10346.
The proposed patch for the issue could not be applied as is
because the SOURCE_DIR always exists for an ExternalProject_Add
call by the time we get to the place to emit the potential error.
The fix is to emit the error only if the source dir is empty.
By which, I mean devoid of files and subdirectories. If
SOURCE_DIR is used by itself, without any DOWNLOAD_COMMAND
or repository info, then it implies that the SOURCE_DIR is ready
to build as-is without need for a download step. Clearly, if it
is empty, then it is not ready to build as is. So complain if
the SOURCE_DIR is empty.
Commit 82c081ba (Fix rpath-link flag for SunPro C++ on Linux,
2009-07-13) taught CMake to pass '-rpath-link' because SunPro C++ 5.9
does not support '-Wl,'. Now SunPro C++ 5.11 does not recognize the
option without using '-Wl,'. Detect whether to use '-Wl,' based on the
output of "sunCC -flags".
Use it from ExternalProject and the ExternalProject test's
CMakeLists file rather than having duplicate find_program calls.
Add logic so that we do not try to use *.cmd variants of git
programs when using the MSYS Makefiles generator. Should fix
the last remaining dashboard issue with the new ExternalProject
git support additions.
Also, correct minor problem regarding placement of the local git
repo during test execution. On clean builds, it was being placed
incorrectly because of the ../.. relative reference. Use an absolute
path to place the local git repo in the proper directory, and only
use the relative reference when referring to it.
