GitLab

As of CMake 2.6 this variable is not defined, and the ANSI flags for the
HP compiler are simply hard-coded in the default C flags.

This compiler does not enable ANSI mode by default.  When identifying
the C compiler we try passing -Aa in case it is the HP compiler.

These member structures are accessed only in the cmTarget implementation
so they do not need to be defined in the header.  This cleanup also aids
Visual Studio 6 in compiling them.

Alex

The config-to-interface map in cmTarget should use case-insensitive
configuration names.  The change avoids repeating work if the given
configuration has a different case than one already computed.

This fixes a dumb logic error introduced by the centralization of link
interface computation.  It prevented link directories from alternate
configurations from getting listed by the OLD behavior of CMP0003 for
targets linked as transitive dependencies.

The comment had a typo and was longer than necessary.

This makes the LinkInterface struct a member of cmTarget, pimplizes the
config-to-interface map, and stores interface instances by value.

This method previously required the global generator to be passed, but
that was left from before cmTarget had its Makefile member.  Now the
global generator can be retrieved automatically, so we can drop the
method argument.

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.

BUG: Allow arbitrary text in values for some keywords. (And avoid warning 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.

BUG: cmd_set logic was missing from update and patch steps. Fix it so that 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.

BUG: Exclude svn portions of ExternalProject test when: svn client version 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.

BUG: Avoid running the cvs portions of the ExternalProject test on non-cygwin builds that are using cygwin cvs.exe.