Previously tests marked with WILL_FAIL have been reported by CTest as
...............***Failed - supposed to fail
when they correctly failed. Now we just report ".....Passed" because
there is no reason to draw attention to something that works as
expected.
Xcode 2.0 and below supported only one configuration, but 2.1 and above
support multiple configurations. In projects for the latter version we
have been generating a "global" set of buildSettings for each target in
addition to the per-configuration settings. These global settings are
not used by Xcode 2.1 and above, so we should not generate them.
The cmGlobalXCodeGenerator::CreateBuildSettings had the three arguments
productName, productType, and fileType that returned information used by only
one of the call sites. This change refactors that information into separate
methods named accordingly.
Previously we named Xcode targets using the output file name from one of the
configurations. This is not very friendly, especially because it changes with
CMAKE_BUILD_TYPE. Instead we should use the original logical target names for
the Xcode target names. This is also consistent with the way the other IDE
generators work.
CMake previously generated Xcode project files labeled as 2.4-compatible
by recent versions of Xcode (3.0 and 3.1). It is better to generate
native Xcode 3.0 and 3.1 projects. In particular, this can improve
build times by using the "Build independent targets in parallel"
feature.
Patch from Doug Gregor. See issue #9216.
files of the project, i.e. there is now a "CMake Files" folder additionally
to the "Sources", "Headers" and "Others" folders which already existed.
Patch by Daniel Teske.
Alex
This cleans up the Makefile generator's progress rule code. Instead of
keeping every cmMakefileTargetGenerator instance alive to generate
progress, we keep only the information necessary in a single table.
This approach keeps most of the code in cmGlobalUnixMakefileGenerator3,
thus simplifying its public interface.
This enhances the Fortran compiler id detection by using a source that
can compile either as free or fixed format. As long as the compiler
knows it should preprocess the source file (.F) the identification can
work. Even free-format compilers may try fixed-format parsing if the
user specifies certain flags, so we must support both.
This creates new module ExternalProject.cmake to replace the prototype
AddExternalProject.cmake module. The interface is more refined, more
flexible, and better documented than the prototype.
This also converts the ExternalProject test to use the new module. The
old module will be removed (it was never in a CMake release) after
projects using it have been converted to the new module.
This test requires a long time on slower machines, so we need to extend
its timeout. It is an important test, so it does not fall under the
CMAKE_RUN_LONG_TESTS option. In the future we should try to shorten the
test by building simpler external projects.
David Cole
Brad King
Alexander Neundorf
Bill Hoffman
Clinton Stimpson