This commit cherry-picks and squashes the following commits:
4685872 "FortranCInterface: Fix PathScale detection..." (2010-02-16)
b39fe94 "Fix problem with ExternalProject test..." (2010-02-17)
70290e1 "Add support for QtDeclartive module" (2010-02-17)
282ba89 "Clarify CMAKE_MODULE_PATH documentation" (2010-02-18)
4eba05d "Suppress GNU flag -fPIC on Windows" (2010-02-19)
57efb4a "BUG: We shouldn't be setting the HideWindow..." (2010-02-19)
CTest 2.6.4 crashes if a dashboard script invokes "message()" after
"ctest_test()" or anything else that creates an inner cmCTest object.
The CMake.Install test drives installation using --build-and-test with
the outer CTest driving CMake tests. We add --force-new-ctest-process
to avoid creation of a cmCTest object inside the outer CTest just in
case it is 2.6.4.
At least one Fortran compiler does not provide a preprocessor symbol to
identify itself. Instead we try running unknown compilers with version
query flags known for each vendor and look for known output. Future
commits will add vendor-specific flags/output table entries.
The flag "-_this_is_not_a_flag_" was not rejected by GCC 4.0 on older
Mac OS X. We now use "---_this_is_not_a_flag_" instead, which will
hopefully be rejected by all compilers.
The CMake.File test runs several scripts through "cmake -P" and checks
the output and result against known good values. This commit factors
out the checking code into a separate CMakeCheckTest module. The module
may be used by new tests.
This commit teaches the FunctionTest to check variable scope behavior
when a subdirectory is added inside a function call. Any PARENT_SCOPE
sets in the subdirectory should affect only the function scope which
called add_subdirectory and not its parent scope.
CMake now looks for a Fortran compiler matching any C or C++ compiler
already enabled. We test this by enabling C and C++ first in the
Fortran test, which is what user projects will likely do.
Visual Studio 10 uses MSBuild to drive the build. Custom commands
appear in MSBuild files inside CustomBuild elements, which appear inside
ItemGroup elements. The Outputs and AdditionalInputs elements of each
CustomBuild element are evaluated according to timestamps on disk.
MSBuild does not use inputs/outputs to order CustomBuild steps within a
single ItemGroup or across multiple ItemGroup elements. Instead we must
put only unrelated CustomBuild elements in a single ItemGroup and order
the item groups from top to bottom using a topological order of the
custom command dependency graph.
This fixes CustomCommand and ExternalProject test failures, so we remove
the expectation of these failures.
Part of this test does "git pull" on a dirty work tree. We need to make
sure that 'branch.master.rebase' is false for the test repository.
Otherwise if it is true in the user configuration then pull will refuse
to rebase and the test will fail.
We teach the FindPackageTest to build a sample project that stores its
build tree in the user package registry using export(PACKAGE), and then
find it with find_package.
We test that LINK_INTERFACE_MULTIPLICITY propagates through export() and
install(EXPORT) into dependent projects. A simple cycle of two archives
that need to be scanned three times ensures that the importing project
uses the multiplicity correctly.
Bill Hoffman
Brad King
Zach Mullen
David Cole
Alexander Neundorf