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.
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.
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.
