The modern cmComputeTargetDepends guarantees there will by no cycles.
Drop the Xcode generator's check which only handled length 1 and 2
cycles anyway.
f616ff2 Update generator to use new cmGeneratorTarget api.
674bd6e Merge branch 'master' into sublime-text-2-generator
4760ead Remove ability to generate sublime clang files.
da0898e Correct missing parameter to CMP0018Flags call.
badb40d Merge branch 'master' into sublime-text-2-generator
b3ae61f Merge branch 'master' into sublime-text-2-generator
089d9cc SublimeText 2 Gen: Set the sublimeclang_options_script property.
44c2eee Merge branch 'master' into sublime-text-2-generator
304b885 Sublime Text 2 Gen: Per-source Compile flags are now saved in a separate file.
5b2aa3d SublimeText2 Gen: Fixed the issue where include directory flags used -D
90bcb77 SublimeText2 Gen: Improved use of define, include flags from CMAKE_C(XX)_FLAGS
cc84072 Merge branch 'master' into sublime-text-2-generator
8670cbe Define flags in CMAKE_C(XX)_FLAGS are now included in SublimeClang settings.
d022d4e Merge branch 'master' into sublime-text-2-generator
9cd3e70 Fixed Sublime Text project generation for in-source builds
44f35f7 Added a CMAKE_SUBLIMECLANG_DISABLED variable that disables SublimeClang.
...
SublimeClang is a optional plugin to SublimeText and I felt it
shouldn't be part of the generator for the following reasons:
1. Reduces the amount of sublime and sublimeClang specific
code we have to maintain inside CMake.
2. In testing the SublimeClang commands generated did not work
for the VTK project.
For people that do want this feature I recommend that they
looking into https://gist.github.com/robertmaynard/4724705 for a
way to use CMAKE_EXPORT_COMPILE_COMMANDS to generate JSON files
that can be used by SublimeClang.
Since the topic merged to master by commit 34a02846 (Merge topic
'ide-compiler-id', 2012-08-24), these variables are not used by
CMakeDetermine*Compiler.cmake for VS and Xcode generators. Drop the
code that sets them.
Since commit e015df7d (...delete CMakeFiles directory when cache is
deleted, 2006-02-20) we deleted the files in the CMakeFiles directory
when deleting CMakeCache.txt in order to reset the build tree to a fresh
state. This allowed commit fd33bf93 (fix for bug 6102, allow users to
change the compiler, 2007-12-13) to delete CMakeCache.txt when the user
changes the compiler and CMakeFiles/CMake<lang>Compiler.cmake and other
platform information files would go with it to allow a fresh start.
Then commit 7195aca5 (Make platform information files specific to the
CMake version, 2012-08-24) moved the platform information files to a
subdirectory e.g. CMakeFiles/<version>/CMake<lang>Compiler.cmake where
<version> is the current CMake version. This causes the compiler change
logic to fail to remove all old compiler information. Then on the next
configuration CMake<lang>Compiler.cmake would set CMAKE_<lang>_COMPILER
back to the old value and re-trigger the compiler change logic. This
causes an infinite loop of cache deletion and compiler reset.
Fix this simply by teaching cmCacheManager::DeleteCache to remove the
entire CMakeFiles directory recursively whenever it removes an existing
CMakeCache.txt. This fully resets the build tree to configure with a
fresh compiler.
Since Xcode doesn't sort the files on its own, let's sort them in our
generator to make navigation easier. Visual Studio, QtCreator, and
kdevelop all display files sorted.
fde949d Don't add target-specific interface includes and defines to Qt 4 targets.
79ae968 Revert "Add a way to exclude INTERFACE properties from exported targets."
71bf96e Revert "find_package: Reword <package>_NO_INTERFACES documentation"
3df36b5 Revert "Add the $<LINKED:...> generator expression."
e1f9080 Don't populate INTERFACE includes and defines properties in tll.
567c8d1 Revert "Don't allow utility or global targets in the LINKED expression."
a1c4905 Use the link information as a source of compile definitions and includes.
5c9f5e3 Don't use LINKED where not needed.
5b88504 Rename the IncludeDirectoriesEntry to be more generic.
b030323 Fix determination of when we're evaluating compile definitions.
The GNU compiler front-ends on AIX invoke the linker with flags of the
form "-L/path/to/gnu/runtime/lib" to tell ld where to find the language
runtime libraries. They depend on the default libpath behavior
documented in "man ld" to add the -L paths also to the runtime libpath
so the dynamic loader can find the language runtime libraries. This
differs from platforms whose linkers have distinct -rpath flags that
non-system compilers can use to tell the dynamic loader where to find
their language runtime libraries.
Since commit 96fd5909 (Implement linking with paths to library files,
2008-01-22) CMake always passes "-Wl,-blibpath:" followed by any
project-defined RPATH plus "/usr/lib:/lib" in order to explicitly set
the runtime libpath and avoid getting all the project -L paths in the
runtime libpath. The explicit libpath prevents the GNU compiler runtime
library -L paths from being placed in the libpath and then the dynamic
loader fails to find the language runtime libraries.
CMake already detects the implicit link directories for each language
since commit 07ea19ad (Implicit link info for C, CXX, and Fortran,
2009-07-23). Add the implicit link directories to the explicit runtime
libpath for GNU compilers on AIX to fix this use case.
Since commit c70beb4b (change the default borland stack size, 2003-05-05),
commit 1b572eb9 (remove -H flags, 2003-05-08), and commit 2d411398 (Stack size
in generated programs should be 10 meg, 2003-06-12) CMake adds link flags to
select a 10MB stack. At the time this was for consistency with our behavior on
MS, but that was recently removed by commit 51af1da3 (Remove "/STACK:10000000"
from default linker flags, 2012-11-23).
Change our Embarcadero link flags to select the default stack and heap settings
according to the compiler documentation. This is more reliable than leaving
the flags out completely as it has been reported that the linker does not
always use its documented defaults.
Suggested-by: Mathäus Mendel <contato@mathausmendel.com>
This reverts commit 2c3654c3de.
The removal of some tests added in commit 77cecb77 (Add includes and compile
definitions with target_link_libraries., 2012-11-05) are also squashed
into this commit.
This is a partial revert of commit 77cecb77 (Add includes and compile
definitions with target_link_libraries., 2012-11-05).
As the interface includes and defines are now determined by the link
closure, there is no need to populate the corresponding properties
explicitly.
After evaluating the INTERFACE_INCLUDE_DIRECTORIES, of a target in a
generator expression, also read the INTERFACE_INCLUDE_DIRECTORIES of
its link interface dependencies.
That means that code such as this will result in the 'user' target
using /bar/include and /foo/include:
add_library(foo ...)
target_include_directories(foo INTERFACE /foo/include)
add_library(bar ...)
target_include_directories(bar INTERFACE /bar/include)
target_link_libraries(bar LINK_PUBLIC foo)
add_executable(user ...)
target_include_directories(user PRIVATE
$<TARGET_PROPERTY:bar,INTERFACE_INCLUDE_DIRECTORIES>)
Also process the interface include directories from direct link
dependencies for in-build targets.
The situation is similar for the INTERFACE_COMPILE_DEFINITIONS. The
include directories related code is currently more complex because
we also need to store a backtrace at configure-time for the purpose
of debugging includes. The compile definitions related code will use
the same pattern in the future.
This is not a change in behavior, as existing code has the same effect,
but that existing code will be removed in follow-up commits.
Brad King
Robert Maynard
Kitware Robot
Neil Carlson
Alexander Chehovsky
Stephen Kelly
Peter Kümmel
Rolf Eike Beer
Mark Salisbury