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.
The TortoiseCVS version of cvs.exe includes the '.exe' in cvs update
messages for files removed from the repository. This change accounts
for it in the regular expressions that match such lines. Now removed
files are properly reported by ctest_update() when using TortoiseCVS.
The test needs to create a cvs repository with 'cvs init', but the CVSNT
client on Windows needs 'cvs init -n' to avoid administrator access.
Previously we required users to explicitly enable CTEST_TEST_UPDATE_CVS
to activate the test on Windows.
This teaches the test to use the '-n' option when necessary. Now we can
enable the test in all cases except when trying to use a cygwin cvs.exe
without cygwin paths.
On HP-UX machines some system libraries appear in architecture-specific
implicit linker search paths. We need to add these paths to our system
library search path. However, at the time we construct the search path
we do not know the target architecture.
A full solution requires re-organizing platform configuration files so
that the target architecture can be known when needed. Until that
happens we can avoid the problem by searching in both 32-bit and 64-bit
implicit link directories. By telling CMake that they are implicit
directories the generated link lines will never pass the paths, leaving
the linker free to find the library of the proper architecture even if
the find_library call finds the wrong one.
This fixes the CMP0012 description to have a one-line summary in the
'brief' section and the rest of the explanation in the 'full' section.
It makes the warning message shorter and improves formatting of the
policy documentation, especially in the HTML pages. The convention is
already used by all other policies.
Errors and warnings from the if() command always display the argument
list given to the command followed by an explanation of the problem.
This moves the argument list into a pre-formatted block and follows it
with a paragraph-form explanation. The result looks cleaner.
In CMake 2.6.3 and below we silently accepted duplicate build
directories whose build files would then conflict. At first this was
considured purely a bug that confused beginners but would not be used in
a real project. In CMake 2.6.4 we explicitly made it an error.
However, some real projects took advantage of this as a "feature" and
got lucky that the subtle build errors it can cause did not occur.
Therefore we need a policy to deal with the case more gracefully.
See issue #9173.
VS 6 forgets to create the output directory for an executable's import
library in case the exe dllexport-s symbols. We work around this VS bug
by creating a pre-link event on the executable target to make the
directory.
In cmLocalVisualStudio6Generator we generate pre-build, pre-link, and
post-build events into project files. This refactors the generation
code for the three event types into a private EventWriter class to avoid
duplicate code.
This moves creation of an executable's import library directory in VS
projects from the pre-build step to the pre-link step. It makes sense
to create the directory at the last moment.
In VS 7,8,9 executable targets we generate a build event to create the
output directory for the import library in case the executable marks
symbols with dllexport (VS forgets to create this directory). This
generalizes computation of the custom command line to support future use
with other VS versions.
Brad King
David Cole
Bill Hoffman
Clinton Stimpson
Ken Martin