This adds
- the variable ``CMAKE_AUTOGEN_ORIGIN_DEPENDS`` which initializes
- the target property ``AUTOGEN_ORIGIN_DEPENDS``
which controls whether or not the origin target dependencies
should be forwarded to the corresponding ``_autogen`` target.
The default value of ``CMAKE_AUTOGEN_ORIGIN_DEPENDS`` is ``ON``
which corresponds to the behavior that is in place since CMake 3.9.
Closes: #18493
This makes binaries independent of the build directory by not embedding
the build directory via RPATH. The tests are partially based on the
existing RuntimePath test, but with the check moved into a POST_BUILD
command such that it can be skipped when the platform lacks support.
Fixes: #18413
36489b85aa VS: Add test for CMAKE_VS_GLOBALS
22e670a306 VS: Add option to set VS_GLOBAL_* for all targets
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2345
These new capabilities enable to manage link directories
Two new properties:
* target properties: LINK_DIRECTORIES and INTERFACE_LINK_DIRECTORIES
One new command
* target_link_directories(): to populate target properties
Fixes: #17215
Previously the command did not allow naming targets on the LHS that
were not created in the calling directory. Lift this restriction to
enable more flexible use by projects.
Targets named on the RHS will need to be looked up during generation in
the scope of the call site rather than the scope of the LHS target.
Introduce an internal syntax in `[INTERFACE_]LINK_LIBRARIES` properties
to specify target names that need to be looked up in a directory other
than that containing the target on which the property is set. Add
minimal documentation of the syntax to help users that encounter it.
Unfortunately CMake previously did allow such calls in the case that
only `INTERFACE` libraries are specified, but those libraries would be
looked up in the target's directory rather than the caller's. Add
policy `CMP0079` to enable the new behavior with new lookup scope in a
compatible way.
Fixes: #17943
The `AddLinkLibrary` method takes a `cmMakefile` pointer to represent
the scope of the caller that wants to link to the named library.
Currently in all call sites this is the same as the target's `Makefile`
member, but in principle the library named by the caller is visible in
its scope so we should use the `cmMakefile` it provided to look up the
library target.
Add `XCODE_SCHEME_*` target properties and associated variables
`CMAKE_XCODE_SCHEME_*` to initialize them on target creation.
Map each target property value to an associated Xcode scheme entry.
Co-Author: Martin Sander <mail@martin-sander.de>
Fixes: #17919
This family enable to manage link flags
Three new properties:
* directory property: LINK_OPTIONS
* target properties: LINK_OPTIONS and INTERFACE_LINK_OPTIONS
Two new commands
* add_link_options(): to populate directory property
* target_link_options(): to populate target properties
Fixes: #16543
Run the `clang-format.bash` script to update all our C and C++ code to a
new style defined by `.clang-format`. Use `clang-format` version 6.0.
* If you reached this commit for a line in `git blame`, re-run the blame
operation starting at the parent of this commit to see older history
for the content.
* See the parent commit for instructions to rebase a change across this
style transition commit.
This can be used for example to organize all following targets into one
Visual Studio folder:
set(CMAKE_FOLDER Libraries)
add_subdirectory(libA)
add_subdirectory(libB)
set(CMAKE_FOLDER Executables)
add_subdirectory(progA)
Another possibility is using the current directory name for all
following targets in subdirectories:
get_filename_component(dirname "${CMAKE_CURRENT_SOURCE_DIR}" NAME)
string(APPEND CMAKE_FOLDER "/${dirname}")
Remove an unused variable and its containing local scope accidentally
left by commit v3.11.0-rc1~44^2 (Reduce allocation of temporary values
on heap, 2018-01-25).
Remove the `<target>_LIB_DEPENDS` cache entry unconditionally.
It will be populated again later if needed. There is no need
to ask the user to remove the cache entry if the target type
changes.
Issue: #16364
Note: This only allows `OBJECT` libraries to be on the right-hand side
of `target_link_libraries` but still does not link its object-files to
the target on the left-hand side.
Issue: #14778
This introduces concurrent thread processing in the `_autogen`
target wich processes AUTOMOC and AUTOUIC.
Source file parsing is distributed among the threads by
using a job queue from which the threads pull new parse jobs.
Each thread might start an independent ``moc`` or ``uic`` process.
Altogether this roughly speeds up the AUTOMOC and AUTOUIC build
process by the number of physical CPUs on the host system.
The exact number of threads to start in the `_autogen` target
is controlled by the new AUTOGEN_PARALLEL target property which
is initialized by the new CMAKE_AUTOGEN_PARALLEL variable.
If AUTOGEN_PARALLEL is empty or unset (which is the default)
the thread count is set to the number of physical CPUs on
the host system.
The AUTOMOC/AUTOUIC generator and the AUTORCC generator are
refactored to use a libuv loop internally.
Closes#17422.
Primarily, this includes:
- the rule files generated for custom targets;
- source files representing custom targets directly;
- outputs of custom commands;
- byproducts of custom commands; and
- dependencies of custom commands.
The ambiguous extension logic is an old behavior that ends up taking
lots of extra compute cycles to execute. This is triggered by various
CMake codepaths which pass extension-less paths down when CMake actually
knows that they are not ambiguous. These codepaths will be indicated in
upcoming changes.
Various APIs have gained a cmSourceFileLocationKind parameter, but they
are all optional and default to the existing behavior.
Add a `Fortran_COMPILER_LAUNCHER` target property like those added for C
and CXX by commit v3.4.0-rc1~450^2 (Add options to launch the compiler
through tools like ccache or distcc, 2015-06-04) and CUDA by commit
v3.10.0-rc1~531^2 (CUDA: Add option to run the compiler through launcher
tools, 2017-06-09).
Fixes: #17499
Some generators auto-generate targets. For example VS generators create
the ALL_BUILD target. Add the ability to mark targets as generator
provided and return that info through cmake-server codemodel.
The purpose of this new `IMPORTED_GLOBAL` target-property is to prolong
the lifetime and scope of `IMPORTED` targets in such a way as if they
had been created with the keyword `GLOBAL` in the first place.
* It can only be set to `TRUE`. That means, a local `IMPORTED` target
can be promoted to global scope but a global `IMPORTED` target cannot
be degraded to local scope!
* Setting it to `TRUE` only succeeds if done from within the same
directory in which the `IMPORTED` target was created in the first
place.
Fixes#17256.
Before this change, `cmTarget::CheckProperty` accepted several strings
as valid properties, including all strings prefixed with
"INTERFACE_LINK_LIBRARIES". Now, that particular string is still
accepted but other strings prefixed with that string are no longer
accepted.
The change in commit v3.8.0-rc1~276^2 (Allow NO_SYSTEM_FROM_IMPORTED on
imported INTERFACE libraries, 2016-11-21) was incorrect. The property
is not meant to be set on imported targets at all. It is meant to be
set on their consumers that compile sources. Since INTERFACE libraries
have no sources to compile, the property is not needed on them.
Revert most of that change. Unfortunately we must still tolerate
project code setting NO_SYSTEM_FROM_IMPORTED on INTERFACE libraries
because they were allowed by CMake 3.8 and 3.9.
Issue: #17348
