| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
This cleans up cmInstallTargetGenerator's code that computes the build
tree location of a target under each configuration.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The documentation of this variable was out-dated and misleading.
See issue #9219.
|
| |
|
|
|
|
|
|
| |
(http://www.cdash.org/CDash/viewBuildError.php?buildid=366375)
Alex
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Tests/Complex/ )
Alex
|
|
|
|
|
|
| |
just a single item is printed
Alex
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
patch by Daniel Teske
Alex
|
| |
|
|
|
|
| |
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 RemoveEscapes method is no longer used anywhere. All uses of it
have been replaced by a real lexer. We can remove the method.
|
|
|
|
|
| |
This documents CMake's support for cycles in the dependency graph of
STATIC libraries.
|
|
|
|
|
| |
The COMPILE_DEFINITIONS properties are semicolon-separated lists.
Make this clear in the documentation. See issue #9199.
|
| |
|
|
|
|
|
|
|
| |
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 disables Borland warning 8027 while compiling KWSys source files.
It provides no useful information.
|
|
|
|
|
| |
This removes an assignment whose result is never used, thus quieting a
warning from Borland.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|