GitLab

Using `xcodebuild -enableAddressSanitizer YES ...` causes object files
to be placed in a different directory name.  Xcode provides a
placeholder for this that we can use in `OTHER_LDFLAGS` to reference
object files for linking the dependents of object libraries.  However,
CMake's features for installing and exporting object libraries depend on
knowing the real path with no placeholders.  For these cases, use the
default object directory.  Users will then have to choose between
sanitizers and the installation and export features, but both will work
individually.

Fixes: #16289

The new optional `before` parameter in `cmTarget::AddSource` and
`cmGeneratorTarget::AddSource` allows to prepend a source file
to the sources list instead of appending it.

bmanga authored Nov 22, 2018 and Brad King committed Jan 16, 2019

Reduce the number of files relying on `cmake.h`.

Sean McBride authored Jan 11, 2019 and Brad King committed Jan 15, 2019

Suppress one in code generated by flex.

wahikihiki authored Nov 19, 2018 and Brad King committed Nov 20, 2018

Fix some warnings that are new since clang-tidy version 4, and update
`.clang-tidy` to suppress the rest.

Fixes: #14983, #16561

Fixes: #16532

A target created by `add_custom_target` should always be a `.vcxproj`
file even if it has `.cs` sources involved in custom commands and such.
The latter case was broken by refactoring in commit v3.12.0-rc1~160^2~7
(remove TargetIsCSharpOnly() and use methods from cmGeneratorTarget,
2018-03-19).  The reason is that the `HasLanguage` method added by
commit v3.12.0-rc1~239^2~6 (cmGeneratorTarget: add HasLanguage() as
wrapper for GetLanguages(), 2018-03-19) does not check the target type
and so is not a suitable check for deciding the project file extension.

The `HasLanguage` method was an attempt at an abstraction that turns
out not to work very well.  Replace it with a dedicated `IsCSharpOnly`
method that considers the target type, sources, and non-transitive
`LINKER_LANGUAGE`.

Fixes: #18515

A target created by `add_custom_target` should always be a `.vcxproj`
file even if it has `.cs` sources involved in custom commands and such.
The latter case was broken by refactoring in commit v3.12.0-rc1~160^2~7
(remove TargetIsCSharpOnly() and use methods from cmGeneratorTarget,
2018-03-19).  The reason is that the `HasLanguage` method added by
commit v3.12.0-rc1~239^2~6 (cmGeneratorTarget: add HasLanguage() as
wrapper for GetLanguages(), 2018-03-19) does not check the target type
and so is not a suitable check for deciding the project file extension.

The `HasLanguage` method was an attempt at an abstraction that turns
out not to work very well.  Replace it with a dedicated `IsCSharpOnly`
method that considers the target type, sources, and non-transitive
`LINKER_LANGUAGE`.

Fixes: #18515

In cmGeneratorTarget and cmLocalGenerator we offer several APIs to get
build settings like include directories, compile definitions, source
files, etc.  Add corresponding APIs that include backtrace information.

Record backtraces for "utility" dependencies created by
`add_dependencies` calls.

Carry a backtrace on every link item, not just link implementation
items.  For now the non-impl items will still have empty backtraces at
runtime, but this will allow us to introduce values over time.

A that target contains only `.cs` sources should be generated as a
`.csproj` project even if it links to non-CSharp static libraries.
The latter case was broken by refactoring in commit v3.12.0-rc1~160^2~7
(remove TargetIsCSharpOnly() and use methods from cmGeneratorTarget,
2018-03-19).  The reason is that the `HasLanguage` method added by
commit v3.12.0-rc1~239^2~6 (cmGeneratorTarget: add HasLanguage() as
wrapper for GetLanguages(), 2018-03-19) enforces its "exclusive" check
on the combined set of source file languages and the link language.
To restore the original `TargetIsCSharpOnly` semantics, update
`HasLanguage` to enforce exclusiveness only on the list of sources.

Fixes: #18239

Marc Chevrier authored Sep 14, 2018 and Craig Scott committed Sep 25, 2018

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

Refactoring in commit f4ff60a8

 (cmMakefile: Make GetSafeDefinition
return std::string const&, 2018-09-05) accidentally changed the logic
for target artifact prefix and suffix names such that setting a PREFIX
or SUFFIX target property would cause an empty value to be used.  Revert
that part of the change and use a simpler alternative.  Add a test case.
Reported-by: Alan W. Irwin <irwin@beluga.phys.uvic.ca>

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

While collecting usage requirements from the `INTERFACE_*` properties of
directly linked targets, we internally generate `TARGET_PROPERTY:` and
`TARGET_OBJECTS:` generator expressions to refer to those properties on
those targets.  At the point we generate these expressions we already
have a pointer to an exact `cmGeneratorTarget` instance.

Switch from using the target name in these generator expressions to
using an internal unique name generated for each `cmGeneratorTarget`
instance to be referenced.  This avoids depending on the user-facing
target name to find the same target we already have.

If two imported targets in different directories have the same name we
should still be able to propagate transitive usage requirements from
both.  Fix the DAG checker to work with target pointers instead of
target names since the pointers will not be duplicated even if the names
are.

Fixes: #18345

If two imported targets in different directories have the same name we
should still be able to propagate transitive link dependencies from
both.  Fix the target and link dependency analyzers to de-duplicate
targets using target pointers rather than target names since the
pointers will not be duplicated even if the names are.

Issue: #18345

Avoid exposing the item name implicitly as std::string.  When the item
is a target, avoid storing a second copy of its name.

Most link item construction is paired with calls to `FindTargetToLink`
to get the possible target pointer.  Rename these methods to
`ResolveLinkItem` and refactor them to construct the entire item.

Vitaly Stakhovsky authored Aug 31, 2018 and Brad King committed Sep 05, 2018

Use the new IsOn(),IsOff() overloads.

issue: #18251

Fixes: #17997

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