3bed969dac cmMakefile: Modernize AddFunctionBlocker method to accept a std::unique_ptr
faacb90a13 cmELF: Modernize to use std::unique_ptr instead of new/delete
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3548
The `AssemblerListingLocation` setting in VS project files is meant for
intermediate files created during the build much like object files.
When the VS 7 generator was first under development, commit 49aebe6c99
(new arch, 2002-09-04) placed both object files and the ASM list
location in the same directory. Later commit f9aef0e422 (Generator now
creates a separate intermediate files directory for each target,
2005-07-27) moved the object files to a per-target directory but the
ASM list location was not moved with them. Move it now.
Fixes: #19480
The Swift driver recently learnt how to generate static libraries using
the `-static` flag. This enables us to generate proper static libraries
with dependency tracking with Swift as well.
When building Swift executables and libraries which import a module, an
implicit link will be added by the driver. Because this links by name
rather than path, the library search path needs to be provided to
indicate where to find the library. For all local dependencies, add the
library paths for the targets when linking. This ensures that you can
link against local libraries without explicitly setting a library path.
Fixes: #19304
This changes the behaviour of the generators to use a per-language
library search path flag. This is needed for multi-language projects
with different compilers (e.g. cl + gfortran). Since the adjusted
variable has been part of the user settings, we control this based on a
policy.
Fixes: #19307
We've long created shared objects on AIX using the linker's `-G` option
(also offered by the XL front-end). The `-G` option implies `-brtl` and
enables runtime linking. This has been largely unnecessary because we
provide all dependencies on the link line and both XL and GNU compilers
offer builtin behavior to export symbols. Since commit 0f150b69d3 (AIX:
Explicitly compute shared object exports for both XL and GNU,
2019-07-11) we compute exports explicitly and consistently.
Therefore runtime linking is no longer necessary for shared objects.
We've also long created executables on AIX using the linker's `-brtl`
option to enable runtime linking in case they load plugins at runtime.
Since commit 9f5c2040bf (AIX: Explicitly compute executable exports for
both XL and GNU, 2019-07-12) and commit 2fa920c0cd (AIX: Create import
library for executables with exports, 2019-07-16) we now provide the
linker enough information to fully resolve symbols in plugins up front.
Therefore runtime linking is no longer necessary for executables.
Drop use of `-G` for creating shared objects and use the XL `-qmkshrobj`
and GCC `-shared` options instead. Both invoke the linker with the
`-bM:SRE -bnoentry` options to create a shared object without runtime
linking enabled. Also drop use of `-brtl` for creating executables.
Issue: #19163
0ba5891ead project: Keep leading `0` in PROJECT_VERSION components
5f84669806 Tests: Factor out RunCMake.project helper macro into module
b1f387a7ea Refactor: Use raw string literals instead of escaping
41b85968d8 Refactor: Use initializer lists instead of `push_back` series
45e85dd2b2 Refactor: Add some `const` to vars
90f91e4d21 Refactor: Replace a "magic" number w/ a named constant
638383c38f Refactor: Eliminate one-time-used variables
9b6a53292f Refactor: Eliminate `sep` from the loop
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3517
On AIX, plugins meant to be loaded into executables via `dlopen` must be
linked with access to a list of symbols exported from the executable in
order to use them (when not using runtime linking). The AIX linker
supports specifying this list as an "import file" passed on the command
line either via the `-bI:...` option or (with a leading `#! .` line) as
a normal input file like any other library file.
The linker import file plays the same role on AIX as import libraries do
on Windows. Teach CMake to enable its import library abstraction on AIX
for executables with the `ENABLE_EXPORTS` target property set. Teach
our internal `ExportImportList` script to optionally generate a leading
`#! .` line at the top of the generated export/import list. Update our
rule for linking an executable with exports to generate a public-facing
"import library" implemented as an AIX linker import file.
With this approach, our existing infrastructure for handling import
libraries on Windows will now work for AIX linker import files too:
* Plugins that link to their executable's symbols will be automatically
linked using the import file on the command line.
* The executable's import file will be (optionally) installed and
exported for use in linking externally-built plugins.
This will allow executables and their plugins to build even if we later
turn off runtime linking.
Issue: #19163
c2c3d22504 Tests: Drop RunCMake workaround for AIX ld warnings about GNU atexit
9f5c2040bf AIX: Explicitly compute executable exports for both XL and GNU
0f150b69d3 AIX: Explicitly compute shared object exports for both XL and GNU
a5bf4e7921 AIX: Drop redundant -brtl flags
9cb5f040d7 XL: De-duplicate shared object creation flags
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3556
In real projects the variable form should rarely be used because the
decision to export symbols from an executable is very specific.
Remove its main description, which duplicates the `ENABLE_EXPORTS`
target property, and simply reference the property instead.
The module mode fallback added by commit 22e65d10c1 (find_package: Fixed
CMAKE_FIND_PACKAGE_PREFER_CONFIG Module fallback, 2019-06-13,
v3.15.0-rc2~6^2) should not be used unless the `find_package` call
allows module mode. Doing so can lead to infinite recursion if a find
module tries to call config mode with `find_package(... NO_MODULE)`.
Fix the logic and add a test case.
Fixes: #19478
Introduce CMake policy `CMP0096` to make `project()` keep leading zeros
in version components. As a side effect, it now allows really long
version numbers.
Fixes: #19421
Co-Author: Brad King <brad.king@kitware.com>
cd6bd8391a FindMatlab: code comment and ordering of the finders
9e6206c59b FindMatlab: fixing extension bat file invocation error
a9b36ea69f FindMatlab: Fixing compilation issues on Windows
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3554
