On AIX, symbols in executables must be exported in order to be visible
to modules (plugins) they load via `dlopen`. Prior to policy `CMP0065`,
CMake linked all executables with flags to export symbols, but the NEW
behavior for that policy is to do so only for executables that have the
`ENABLE_EXPORTS` target property set. In both cases, CMake has always
used the AIX linker option `-bexpall` option to export symbols from
executables.
This has worked fairly well with the XL compiler, but with the GNU
compiler it works only for C ABI symbols. The reason is that `-bexpall`
does not export symbols starting in `_` but the GNU C++ ABI mangles all
symbols with a leading `_`. Therefore we have only supported C ABI
plugins with the GNU compiler on AIX. Some projects have tried to work
around this by replacing `-bexpall` with `-bexpfull`, but the latter
often exports symbols that we do not want exported.
Avoid using `-bexpall` for executables by instead using by our own
internal `ExportImportList` script to compute symbol export lists from
the object files to be linked into an executable. Pass the explicitly
computed export list to the AIX linker's `-bE:...` option. We already
do this for shared object exports.
Issue: #19163
An old workaround for `std::allocator_traits<>::value_type` lints from
IWYU on `std::vector<>` usage breaks IWYU's handling of `<memory>`.
Convert the workaround to use the same approach we already use for a
workaround of `std::__decay_and_strip<>::::__type` lints. Then update
the `<memory>` inclusions to follow the now-correct IWYU lints.
Avoid creating unnecessary `cmCompileGeneratorExpression` instances.
Use runtime polymorphism to avoid the full genex infrastructure when a
property value does not contain a genex.
Issue: #18965
Rather than taking a number of out parameters for the various names,
create a structure that is reused for both `GetLibraryNames` and
`GetExecutableNames`. Replace uses according to the new interface.
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
3e867ed400 cmake: inlined files dir constant and removed it from cmake.h
Acked-by: Kitware Robot <kwrobot@kitware.com>
Rejected-by: vvs31415 <vstakhovsky@fastmail.com>
Merge-request: !2655
1ed4d48dcf Autogen: Prepend instead of append `mocs_compilation.cpp` to the sources list
a42b700cc2 cmTarget,cmGeneratorTarget: Add optional `before` parameter to AddSource
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Peter Wu <peter@lekensteyn.nl>
Merge-request: !2815
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.
9040df31e2 Merge branch 'backport-fix-custom-target-with-csharp'
1acd1c2b50 CSharp: Fix regression in VS project type selection for custom target
a56edad6d6 CSharp: Fix regression in VS project type selection for custom target
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2549
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.
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.
375b420fdf CSharp: Fix regression in VS project type selection
8b21aa0af0 VS: Fix CSharp flag selection when linking to a static C++ library
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2427
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
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 f4ff60a803 (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
