Some compilers do not offer an option to specify the path to the object
file, but rather only to the directory in which to place the object
file. See issue 14876 for some examples. Add a new OBJECT_FILE_DIR
placeholder to specify the directory containing the object file for the
current compilation. This may differ from the main target OBJECT_DIR
when the object corresponds to a source in a subdirectory.
Until now the cmCustomCommandGenerator was used only to compute the
command lines of a custom command. Generalize it to get the comment,
working directory, dependencies, and outputs of custom commands. Update
use in all generators to support this.
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.
Since commit v2.8.12~437^2~2 (VS: Separate compiler and linker PDB files
2013-04-05) we no longer set /Fd with the PDB_NAME or PDB_OUTPUT_DIRECTORY
properties. Those properties now exclusively handle linker PDB files.
Since STATIC libraries do not link their compiler PDB file becomes more
important. Add new target properties "COMPILE_PDB_NAME[_<CONFIG>]" and
"COMPILE_PDB_OUTPUT_DIRECTORY[_<CONFIG>]" to specify the compiler PDB
file location and pass the value to the MSVC /Fd option.
Use a uint64_t to store encoded version numbers so we have plenty of
bits available. Encode with room for up to 1000 minor releases between
major releases and to encode dates until the year 10000 in the patch
level. This is necessary because CMake development versions prior to
release 2.8.0 used the date in the patch level, and this practice may be
restored after the 3.0 release.
Drop all behavior activated by setting CMAKE_BACKWARDS_COMPATIBILITY to
a value lower than 2.4, and generate an error when projects or the user
attempt to do so. In the error suggest using a CMake 2.8.x release.
Teach cmake_minimum_required to warn about projects that do not require
at least CMake 2.4. They are not supported by CMake >= 3.0.
Replace the documentation of CMAKE_BACKWARDS_COMPATIBILITY with a
reference to policy CMP0001.
9cf3547 Add the INTERFACE_SYSTEM_INCLUDE_DIRECTORIES target property.
1925cff Add a SYSTEM parameter to target_include_directories (#14180)
286f227 Extend the cmTargetPropCommandBase interface property handling.
83498d4 Store system include directories in the cmTarget.
f1fcbe3 Add Target API to determine if an include is a system include.
2679a34 Remove unused variable.
Drop the "vsProjectFile" argument from cmTarget::TraceDependencies. It
appears to be the modern equivalent to a hunk added in commit ba68f771
(...added new custom command support, 2003-06-03):
+ name = libName;
+ name += ".dsp.cmake";
+ srcFilesToProcess.push(name);
but was broken by refactoring at some point. The current behavior tries
to trace dependencies on a source file named the same as a target, which
makes no sense. Furthermore, in code of the form
add_executable(foo foo.c)
add_custom_command(OUTPUT "${somewhere}/foo" ... DEPENDS foo)
the "vsProjectFile" value "foo" matches source "${somewhere}/foo.rule"
generated to hold the custom command and causes the command to be added
to the "foo" target incorrectly.
Simply drop the incorrect source file trace and supporting logic.
Replace the cmLocalGenerator GetCompileOptions method with an
AddCompileOptions method since all call sites of the former simply
append the result to a flags string anyway.
Add a "lang" argument to AddCompileOptions and move the
CMAKE_<LANG>_FLAGS_REGEX filter into it. Move the call sites in each
generator to a location that has both the language and configuration
available. In the Makefile generator this also moves the flags from
build.make to flags.make where they belong.
Factor appending of individual flags out into an AppendFlagEscape method
in cmLocalGenerator and teach it to use EscapeForShell. Update all
COMPILE_OPTIONS handling to use AppendFlagEscape.
Override the method in the Xcode generator to use its custom escape
implementation.
Teach the CompileOptions test to add an option that requires escaping
everywhere instead of just with the GNU tools.
This is initialized by CMAKE_<LANG>_VISIBILITY_PRESET. The target
property is used as the operand to the -fvisibility= compile option
with GNU compilers and clang.
Currently it only adds the contents of the COMPILE_FLAGS target
property, but it can be extended to handle a new COMPILE_OPTIONS
generator expression enabled property.
Since commit 08cb4fa4 (Process generator expressions in the
INCLUDE_DIRECTORIES property., 2012-09-18), it is possible to use
generator expressions with the include_directories command.
As that command can also have a SYSTEM argument, ensure that the
result of using that argument with generator expressions gives a
sane result.
This allows a dependee to inform a target that it should have its
POSITION_INDEPENDENT_CODE property set to ON, or OFF. The value of
the POSITION_INDEPENDENT_CODE property, if set, must be consistent
with any INTERFACE_POSITION_INDEPENDENT_CODE properties on dependees.
Add a test covering the consistency checks on platforms where they run.
This should finally fix#13667 and #13762.
Instead of adding special handling to guess whether implicit include dirs
may have been removed, simply make it possible to query the include dirs
without removing the implicit ones.
Alex
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.
1e47ccb Ninja: add option to enforce usage of response files
e31df03 Ninja: move <OBJECTS> in front of the first linker option
8d674e7 Ninja: move -LIBPATH behind -link option
There is no need to do so. Be consistent with include directories and
ensure uniqueness.
This requires changing the API of the cmLocalGenerator::AppendDefines
method, and changing the generators to match.
The test unfortunately can't test for uniqueness, but it at least verifies
that nothing gets lost.
eb410e8 Ninja: disable cldeps for bcc32, it's too old, and ninja would also not build
5ead31d Ninja: try work around for bcc32 bug
1333b57 Ninja: build server fixes
9081e3a remove warning about unused parameter
f430bea Ninja: maybe this fixes the bcc32 build
f2c1288 Ninja: msvc6 for-scoping
44b9bbc Ninja: build with old msvc versions
57156a5 Ninja: build server fixes
f1abdce Ninja: some bytes of the rc files couldn't be piped correctly
2de963d Ninja: don't remove space between command and parameters
50b6f33 Ninja: build cmcldeps with mingw
c05653e Ninja: try to make GetProcessId visible
ab245ff Ninja: but cl supports /nologo ...
bf58e9a Ninja: no /nologo option in old rc.exe
2fb07fc Ninja: Eclipse and KDevelop fixes for ninja
518c065 Ninja: don't pollute build dir with preprocessed rc files
...
CMAKE_SHARED_LIBRARY_<lang>_FLAGS has flags on various platforms for a
variety of purposes that are correlated with shared libraries but not
exclusive to them. Refactor generation of these flags to use new
purpose-specific platform variables
CMAKE_<lang>_COMPILE_OPTIONS_DLL
CMAKE_<lang>_COMPILE_OPTIONS_PIC
CMAKE_<lang>_COMPILE_OPTIONS_PIE
Activate the DLL flags specifically for shared libraries. Add a new
POSITION_INDEPENDENT_CODE target property to activate PIC/PIE flags, and
default to true for shared libraries to preserve default behavior.
Initialize the new property from CMAKE_POSITION_INDEPENDENT_CODE to
allow easy global configuration in projects.
Although the default behavior is unchanged by this refactoring, the new
approach ignores CMAKE_SHARED_LIBRARY_<lang>_FLAGS completely. We must
leave it set in case projects reference the value. Furthermore, if a
project modifies CMAKE_SHARED_LIBRARY_<lang>_FLAGS it expects the new
value to be used. Add policy CMP0018 to handle compatibility with
projects that modify this platform variable.
Add a PositionIndependentCode test on platforms where we can get
meaningful results.
Add a boolean target property NO_SONAME which may be used to disable
soname for the specified shared library or module even if the platform
supports it. This property should be useful for private shared
libraries or various plugins which live in private directories and have
not been designed to be found or loaded globally.
Replace references to <CMAKE_SHARED_LIBRARY_SONAME_${LANG}_FLAG> and
hard-coded -install_name flags with a conditional <SONAME_FLAG> which is
expanded to the value of the CMAKE_SHARED_LIBRARY_SONAME_${LANG}_FLAG
definition as long as soname supports is enabled for the target in
question. Keep expanding CMAKE_SHARED_LIBRARY_SONAME_${LANG}_FLAG in
rules in case third party projects still use it. Such projects would
not yet use NO_SONAME so the adjacent <TARGET_SONAME> will always be
expanded. Make <TARGET_INSTALLNAME_DIR> NO_SONAME aware as well. Since
-install_name is soname on OS X, this should not be a problem if this
variable is expanded only if soname is enabled.
The Ninja generator performs rule variable substitution only once
globally per rule to put its own placeholders. Final substitution is
performed by ninja at build time. Therefore we cannot conditionally
replace the soname placeholders on a per-target basis. Rather than
omitting $SONAME from rules.ninja, simply do not write its contents for
targets which have NO_SONAME. Since 3 variables are affected by
NO_SONAME ($SONAME, $SONAME_FLAG, $INSTALLNAME_DIR), set them only if
soname is enabled.
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
Remove partial implementation added by commit ca0230a3 (check in initial
conv library stuff, 2007-02-16) since it was never finished. It does
not make sense for multi-configuration generators since no specific
build configuration is processed at CMake time.
Eliminate callers of cmMakefile::GetIncludeDirectories.
All callers of GetIncludeDirectories should go through the local generator
object.
Only the local generator calls cmTarget::GetIncludeDirectories directly.
Define a "Fortran_FORMAT" target and source file property. Initialize
the target property from a "CMAKE_Fortran_FORMAT" variable. Interpret
values "FIXED" and "FREE" to indicate the source file format. Append
corresponding flags to the compiler command line.
Create platform option CMAKE_<lang>_USE_RESPONSE_FILE_FOR_INCLUDES to
enable use of response files for passing the list of include directories
to compiler command lines.
The cmCustomCommandGenerator::GetCommand method completely replaces the
purpose of this method. Re-implement GetRealLocation inline at the only
remaining call site and remove it.
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.
Response files are parsed by tools, not by shells. We teach
cmLocalGenerator::Convert() a new "RESPONSE" output format and use it
for objects listed in response files. It does not do special slash or
MSYS root translation like the "SHELL" format does. This is necessary
for GNU tools on Windows to understand response file content.
See issue #10401.
The CMAKE_OSX_ARCHITECTURES variable works only as a global setting.
This commit defines target properties
OSX_ARCHITECTURES
OSX_ARCHITECTURES_<CONFIG>
to specify OS X architectures on a per-target and per-configuration
basis. See issue #8725.
This creates cmTarget::GetFeature and cmMakefile::GetFeature methods to
query "build feature" properties. These methods handle local-to-global
scope and per-configuration property lookup. Specific build features
will be defined later.
This converts the CMake license to a pure 3-clause OSI-approved BSD
License. We drop the previous license clause requiring modified
versions to be plainly marked. We also update the CMake copyright to
cover the full development time range.
In cmLocalGenerator::ConvertToRelativePath we normally convert to
relative path only if the local and remote paths both lie inside the
source tree or both lie inside the build tree. This commit adds an
optional 'force' argument to allow conversion even when this rule is
violated.
This method tells the cmMakefile to read the input CMakeLists.txt file.
We factor out the call into a ReadInputFile method so it can be extended
without polluting the Configure method.
Much of the code in this method was dedicated to computing ObjectMaxPath
after configuring the directory. We move this last step into its own
ComputeObjectMaxPath method for better organization.
This fixes CMAKE_<LANG>_IMPLICIT_INCLUDE_DIRECTORIES to be used for all
generators instead of just those that construct their own compiler
command lines directly. See issue #8598.
We used to suppress generation of -I/usr/include (and on OSX also
-I/usr/local/include). This behavior seems to cause more trouble than
it's worth, so I'm removing it until someone encounters the original
problem it fixed. See issue #8598.
This defines global, directory, and target properties
RULE_LAUNCH_COMPILE, RULE_LAUNCH_LINK, and RULE_LAUNCH_CUSTOM. Their
values specify 'launcher' command lines which are prefixed to compile,
link, and custom build rules by Makefile generators.
When an object file directory is too deep to place an object file
without exceeding CMAKE_OBJECT_PATH_MAX, this issues a warning.
Previously we silently ignored the problem. See issue #7860.
When computing the maximum length full path to the build directory under
which object files will be placed, pass the actual path instead of just
its length. This will be useful for error message generation.
These changes refactor cmLocalGenerator methods Convert and
ConvertToOutputForExisting to support references inside the build tree
using relative paths. After this commit, all tests pass with Makefile
generators when relative paths are enabled by default. See issue #7779.
A Mac OS X Framework should provide a Resources/Info.plist file
containing meta-data about the framework. This change generates a
default Info.plist for frameworks and provides an interface for users to
customize it.
Some native build tools, particularly those for cross compiling, may
have a limit on the length of the full path to an object file name that
is lower than the platform otherwise supports. This change allows the
limit to be set by the project toolchain file through the variable
CMAKE_OBJECT_PATH_MAX.
Brad King
Ben Boeckel
Jiri Malak
Stephen Kelly
Nils Gladitz
Patrick Gansterer
Alex Neundorf
Peter Kümmel
David Cole
Modestas Vainius
Yury G. Kudryashov
Nicolas Despres
Peter Collingbourne
Bill Hoffman