A cycle exists when the DFS returns to the root node, not just when
multiple paths lead to the same node.
Inspired-By: Alexander Esilevich <aesilevich@pathscale.com>
Evaluate in the COMMAND arguments of custom commands the generator
expression syntax introduced in commit d2e1f2b4 (Introduce "generator
expressions" to add_test, 2009-08-11). These expressions have a syntax
like $<TARGET_FILE:mytarget> and are evaluated during build system
generation. This syntax allows per-configuration target output files to
be referenced in custom command lines.
The target_link_libraries command requires its first argument to be a
target in the current directory. Document this and update the error
message to be more specific. While at it, format the error message with
a call stack.
Previously the OUTPUT arguments of add_custom_command were not
slash-normalized but those of add_library and add_executable were.
This caused the example
add_custom_command(OUTPUT a//b.c ...)
add_library(... a//b.c ...)
to fail at build time with "no rule to make a/b.c". Fix this and modify
the CustomCommand test to try it.
This method replaces '//' with '/' to make the paths look nicer.
Originally it correctly skipped a leading '//' in a UNC path as the
comment says. However, commit "Removed extra variable initializations"
(2005-04-15) accidentally removed the "pos=1" initializer. It was then
incorrectly restored by commit "Added missing variable initialization"
(2005-04-15) as just "pos=0". Restore the proper initializer.
The test for this added by commit "better coverage" (2006-07-31)
included incorrect output for a sample UNC-like path. Fix it.
Pass the full version to cmake_minimum_required(VERSION) in generated
CMake files for try_compile projects. This tells CMake not to use any
backward compatibility behavior while processing code it generates.
27ee50a Add ECLIPSE_CDT4_GENERATE_SOURCE_PROJECT as a ADVANCED cache variable (#9631)
50d21d4 Add cache var CMAKE_ECLIPSE_MAKE_ARGUMENTS when using the Eclipse generator
10f01ae Remove unused parameter "root" in some VS generator methods
57e7153 Avoid msbuild idiosyncrasy that builds multiple configs (#11594)
7728172 Remove unused variable "rootdir" in VS generators
Remove a boolean parameter of cmGlobalGenerator::CreateGlobalTarget that
is never set to true anymore. Remove global target "consolidation" loop
because no global targets exist before it runs anymore.
Commit e01cce28 (Allow add_dependencies() on imported targets,
2010-11-19) started using cmMakefile::FindTargetToUse to follow
dependencies, including those of GLOBAL_TARGETs like INSTALL and
PACKAGE. Since global targets exist in every directory, dependencies
between them must be traced within each directory too.
Teach FindTargetToUse to check the current directory before checking
globally. For global targets this will find the local copy. For for
normal targets this will be a no-op because they are globally unique.
This variable can be set to command line arguments which will be passed
to make when eclipse invokes make, e.g. you can enter "-j8" to get
8 parallel builds (#9930)
Alex
This authorize more control because one can set
CPACK_ARCHIVE_COMPONENT_INSTALL to ON globally
and then set it selectively to OFF inside
a CPack project config file.
Sidenote: GetOption ought to be a 'const' method.
If a .sln file refers to a project file with a leading ".\", as in
".\foo.vcxproj" instead of just "foo.vcxproj" or a full path then
msbuild behaves strangely. Whenever target foo is built as a dependency
of another target, msbuild brings multiple configurations up to date
instead of just the requested configuration!
Refer to all project files by full path to avoid this behavior.
The soname generation code was compile-time selected instead of runtime
selected. The result is that a Mac-compiled cmake used to cross-compile
Mac -> Unix generates an soname of the form libfoo.x.y.so instead of
libfoo.so.x.y as expected. Instead do a runtime check based on the
target platform.
Inspired-By: George Staikos <staikos@kde.org>
Avoid tracing dependencies of GLOBAL_TARGET targets. The build system
generators are not designed to handle any dependencies that may be
discovered. Global targets are only generated by CMake and never have
commands that reference targets built in the project anyway.
The exception is when building CMake itself there is a special case to
use the just-built "cmake" binary in the "install" target so that CMake
can replace itself on Windows. Even in this special case we do not want
to let the "install" target depend on the "cmake" target. Doing so
breaks cases like "make -j4 install".
Commit "merge in changes for beos support" (2006-12-04) added a realpath
call for every directory parsed out of a PATH-style environment
variable. No reason was given in the commit message or comments.
The call incorrectly resolves symlinks in referenced paths. Remove it.
If BeOS support really needs it then it can be restored for that
platform with a full explanation.
The cmCustomCommandGenerator::GetCommand method completely replaces the
purpose of this method. Re-implement GetRealLocation inline at the only
remaining call site and remove it.
The Makefile, VS, and Xcode generators previously duplicated some custom
command line generation code. Factor this out into a separate class
cmCustomCommandGenerator shared by all generators.
A custom command may name a target created by add_custom_target in its
DEPENDS field. Treat this case as a target-level dependency only since
a custom target provides no standard file on which to add a file-level
dependency.
