| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Fixes: #22929
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Divert LCC compiler as a new one, instead of treating it as GNU.
Since old times, Elbrus C/C++/Fortran Compiler (LCC) by MCST has been
passing checks for GNU compilers, so it has been identified as GNU.
Now, with intent of seriously upstreaming its support, it has been
added as a separate LCC compiler, and its version displays not a
supported GCC version, but LCC version itself (e.g. LCC 1.25.19 instead
of GNU 7.3.0).
This commit adds its support for detection, and also converts basically
every check like 'is this compiler GNU?' to 'is this compiler GNU or
LCC?'. The only places where this check is untouched, is where it
regards other platforms where LCC is unavailable (primarily non-Linux),
and where it REALLY differs from GNU compiler.
Note: this transition may break software that are already ported to
Elbrus, but hardly relies that LCC will be detected as GNU; still such
software is not known.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In a per-component installation the generated installation scripts
are invoked once for each component.
Per default custom installation script code added by install(CODE|SCRIPT)
only runs for one specific component in this context.
The new ALL_COMPONENTS option allows custom script code to be run once
for each component being installed.
|
|
|
|
| |
Co-Authored-by: Kyle Edwards <kyle.edwards@kitware.com>
|
|
|
|
| |
Co-Authored-by: Kyle Edwards <kyle.edwards@kitware.com>
|
|
|
|
|
|
| |
This object will contain more detailed directory-level information.
Co-Authored-by: Kyle Edwards <kyle.edwards@kitware.com>
|
|
|
|
| |
Make it available to more parts of the codemodel object.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
INTERFACE libraries with SOURCES now appear in the generated
buildsystem, so include them in the codemodel output too.
We do not need to bump the `codemodel-v2` object kind minor
version because that was already done in post-3.18 development
by commit 7d6861f367 (fileapi: Extend codemodel targets with
language standard, 2020-06-18).
Fixes: #18608
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Co-Authored-by: vector-of-bool <vectorofbool@gmail.com>
|
|
|
|
|
| |
Support backtraces for COMPILE_DEFINITIONS, COMPILE_OPTIONS, and
INCLUDE_DIRECTORIES source properties.
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| | |
d70a0f8681 fileapi: Fix codemodel target install destination for cross-dir rules
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3639
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since commit e89ad0f94e (install: Allow installing targets created in
another directory, 2018-06-18, v3.13.0-rc1~407^2) we support calling
`install(TARGETS)` for targets created in another directory. However,
install generators are associated with the directory in which the call
to `install()` appears. This may not be the same directory in which the
target is defined. Record in each target the list of install generators
it has.
Fixes: #19546
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
Issue: #18398
Co-Author: Kyle Edwards <kyle.edwards@kitware.com>
|
|
|
|
|
|
|
|
|
| |
Offer clients a `project()`-centric view of the build system. This is
similar to the directory-centric view but consolidates subdirectories
that do not call `project()` with a new project name.
Issue: #18398
Co-Author: Kyle Edwards <kyle.edwards@kitware.com>
|
| |
|
|
Start with v2 to distinguish it from server-mode v1.
Issue: #18398
|