Since commit 84fdc9921 (stringapi: Pass configuration names as strings,
2014-02-09), it is not safe to use GetDefinition("CMAKE_BUILD_TYPE")
without checking the return value. Use GetSafeDefinition instead so
that a missing definition is treated as an empty string like code paths
did prior to the above commit.
Reported-by: Richard Wirth <richard@califax.de>
Disallow the use of config-specific source files with
the Visual Studio and Xcode generators. They don't have
any way to represent the condition currently.
Use the same common-config API in cmQtAutoGenerators. While
it accepts config-specific files, it doesn't have to support
multiple configurations yet.
Loop over the configs in cmTargetTraceDependencies
and cmGlobalGenerator::WriteSummary and consume all source
files.
Loop over the configs in cmComputeTargetDepends and compute the
object library dependencies for each config.
Distinguish "Open Watcom" from old "Watcom" by introducing a new
"OpenWatcom" compiler id. The __WATCOMC__ format is "VVRP" for Watcom
and "VVRP + 1100" for Open Watcom.
Use the clang RemoveCStrCalls tool to automatically migrate the
code. This was only run on linux, so does not have any positive or
negative effect on other platforms.
Casts from std::string -> cmStdString were high on the list of things
taking up time. Avoid such implicit casts across function calls by just
using std::string everywhere.
The comment that the symbol name is too long is no longer relevant since
modern debuggers alias the templates anyways and the size is a
non-issue since the underlying methods are generated since it's
inherited.
Refactor edit_cache tool selection to ask each global generator for its
preference. Teach the Ninja generator to always use cmake-gui because
Ninja by design cannot run interactive terminal dialogs like ccmake.
Teach the Makefile generator to use cmake-gui when also using an "extra"
generator whose IDE has no terminal to run ccmake, and otherwise fall
back to CMAKE_EDIT_COMMAND selection for normal Makefile build systems.
The API for retrieving per-config COMPILE_DEFINITIONS has long
existed because of the COMPILE_DEFINITIONS_<CONFIG> style
properties. Ensure that the provided configuration being generated
is also used to evaluate the generator expressions
in cmTarget::GetCompileDefinitions.
Both the generic COMPILE_DEFINITIONS and the config-specific
variant need to be evaluated with the requested configuration. This
has the side-effect that the COMPILE_DEFINITIONS does not need to
be additionally evaluated with no configuration, so the callers can
be cleaned up a bit too.
Commit 08cb4fa4 (Process generator expressions in the
INCLUDE_DIRECTORIES property, 2012-09-18) contained an incorrect
assumption that CMAKE_BUILD_TYPE was set on the makefile for each
generated configuration in multi-config generators. Fix that by making
the GetIncludeDirectories API depend on the config.
This commit creates a dummy text file for each OBJECT library for
the CodeBlocks generator, so the generated project file can reference
a unique file for each target. Most probably these files are unused.
Alex
d662dff Fix shadowed variable warning on dashboard results
f66e735 Fix compiler warning reported on older Borland dashboard.
d90eed4 Fix compiler error reported on older Borland dashboard.
8233636 Update the documentation regarding INCLUDE_DIRECTORIES.
d899eb7 Call ExpandVariablesInString for each target's INCLUDE_DIRECTORIES
c21db87 Make search paths ordered and unique
22021f0 Remove cmMakefile::GetIncludeDirectories
9106b56 Extract and use the INCLUDE_DIRECTORIES target properties.
840509b Keep the INCLUDE_DIRECTORIES target property up to date.
a4d5f7b Add API to get the ordered includes for a target.
8adaee2 CMake: Eliminate cmMakefile::IncludeDirectories
7620932 Remove include flags memoization.
97a5faa Make it safe to call this method without creating duplicates.
edd5303 Refactor GetIncludeFlags to take includes instead of fetching them
The purpose of the TargetType enumeration was overloaded for install
type because install rules were once recorded as targets. Factor the
install types out into their own enumeration.
Eliminate callers of cmMakefile::GetIncludeDirectories.
All callers of GetIncludeDirectories should go through the local generator
object.
Only the local generator calls cmTarget::GetIncludeDirectories directly.
e2e8c0a Also put builtin include dirs into CodeBlocks project file
92c0dc5 Remove useless line of code
a5683f8 Patch by Campbell Barton: puts definitions into C::B project file
Refactor code from CMakeFindEclipseCDT4.cmake so it can be used
alkso for CodeBlocks, and move it into new file
CMakeExtraGeneratorDetermineCompilerMacrosAndIncludeDirs.cmake.
Alex
Since CMake 2.6.3 add_custom_target() has a SOURCES option, this was not
yet considered in the C::B generator.
Also, now GENERATED files are not added to the project.
Alex
Instead of enforcing verbose makefile, now the generated build command
includes "VERBOSE=1" so the output will be verbose when building in
C::B.
Also removed the now unused setForceVerboseMakefiles().
Alex
The CodeBlocks generator used to omit files that were in siblings directories.
Though that filters out a few files that could be argued aren't of interest
to the user, it also potentialy hides files that are relevant to the user.
Patch by Daniel Teske.
Alex
See: http://bugreports.qt.nokia.com/browse/QTCREATORBUG-2250 for an example.
The compiler id is checked for C++ and C, if there is not one
of those available, then just default to gcc. This makes it
work with Fortran, or None projects.
Both generators use the CMAKE_EDIT_COMMAND variable to determine whether
they should add the edit_cache target, i.e. they don't add it if it's
ccmake, since this does not work inside the output log view of
Eclipse/Codeblocks. But instead of requiring the variable to be set they now
check it for 0 and handle this appropriately. This should help Dave getting
some testing for them :-)
Alex
Stephen Kelly
Nils Gladitz
Brad King
Jiri Malak
Ben Boeckel
Peter Kümmel
David Cole
Alex Neundorf
Clinton Stimpson
Bill Hoffman