| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
When LINK_INTERFACE_LIBRARIES is not set we use the link implementation
to implicitly define the link interface. These changes centralize the
decision so that all linkable targets internally have a link interface.
|
|
|
|
|
|
| |
This moves code implementing policy CMP0004 into cmTarget::CheckCMP0004.
The implementation is slightly simpler and can be re-used outside of
cmComputeLinkDepends.
|
|
|
|
|
|
| |
This fixes cmTarget::GetLinkInterface to compute and return the link
interface in an exception-safe manner. We manage the link interface
returned by cmTarget::ComputeLinkInterface using auto_ptr.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This teaches the makefile generators to always pass the configuration
name to the cmTarget::GetDirectory method. Later this will allow
per-configuration target output directories, and it cleans up use of the
current API.
|
|
|
|
|
|
| |
This creates cmTarget::GetOutputInfo to compute, cache, and lookup
target output directory information on a per-configuration basis. It
avoids re-computing the information every time it is needed.
|
|
|
|
|
|
|
| |
Since utility targets have no main output files like executables or
libraries, they do not define an output directory. This removes a call
to cmTarget::GetDirectory from cmLocalVisualStudio{6,7}Generator for
such targets.
|
|
|
|
|
| |
In cmLocalVisualStudio{6,7}Generator this replaces a large if() test
with a re-usable result stored in a boolean variable named accordingly.
|
|
|
|
|
|
| |
This member stores the build configuration for which Makefiles are being
generated. It saves repeated lookup of the equivalent member from
cmLocalUnixMakefileGenerator3, making code shorter and more readable.
|
|
|
|
|
| |
This cleans up cmInstallTargetGenerator's code that computes the build
tree location of a target under each configuration.
|
| |
|
|
|
|
| |
that the arbitrary text is an unknown keyword.)
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
UPDATE_COMMAND "" means "no update step even though this is a CVS/SVN repository..."
|
| |
|
|
|
|
|
| |
These tests cannot run with cygwin tools unless testing cygwin CTest.
The version control tools do not understand all Windows paths.
|
|
|
|
| |
is less than 1.2 or cygwin/non-cygwin mismatch detected -- avoids ExternalProject test failures on dash5 and dash22-cygwin. Also, non-code change: allow cvslock through Windows firewall to prevent ExternalProject test failure on dash1vista32.
|
| |
|
| |
|
|
|
|
|
| |
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.
|
|
|
|
| |
non-cygwin builds that are using cygwin cvs.exe.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Tests/Complex/ )
Alex
|
|
|
|
|
|
| |
just a single item is printed
Alex
|
|
|
|
|
|
| |
something different from "C", by resetting them to "C" (#9122)
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
|
| |
|
|
|
|
| |
(rather than 1.4) so that it works (hopefully) with more svn clients in the wild. Change time stamps of test projects in CMakeLists.txt to reflect times available in newly created repository. Add UPDATE_COMMAND "" for checkouts that are tag-based or date-stamp-based to avoid unnecessary update steps.
|
| |
|
|
|
|
| |
available. Add 'configure' step to the repository extraction 'projects' to print the version number of CVS and SVN in the dashboard test/build output.
|
| |
|
| |
|
| |
|
|
|
|
| |
to avoid network activity. Also: stop building KWStyle and kwsys as part of this test to reduce the amount of time spent running the test. Instead, build TutorialStep1 as retrieved from the new local repositories with various tags, date stamps and revision numbers.
|
| |
|
| |
|
| |
|