| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using ccache with clang-tidy, ccache needs to wrap compiler
invocation, rather than cmake invocation. But it needs to do it without
affecting the command line that iwyu-like tools are receiving.
With this fix, if __run_co_compile is used, compile launcher is passed
using the new --launcher option, but if __run_co_compile is not needed,
compiler launcher is prepended to the command line as before.
To better illustrate the change: with this fix if running clang-tidy
with CXX_COMPILER_LAUNCHER set to "/usr/bin/time;-p;ccache" (time -p
added strictly for illustration purposes), the command line changes
from:
/usr/bin/time -p ccache cmake -E __run_co_compile \
--tidy=clang-tidy ... -- g++ ...
to:
cmake -E __run_co_compile \
--launcher="/usr/bin/time;-p;ccache" \
--tidy=clang-tidy ... -- g++ ...
This allows the compiler to be run via the launcher, but leaves tidy
(& friends) invocations unaffected.
Fixes: #16493
|
|
|
|
|
|
|
|
|
|
| |
* Change some functions to take `std::string` instead of
`const char*` in the following classes: `cmMakeFile`, `cmake`,
`cmCoreTryCompile`, `cmSystemTools`, `cmState`, `cmLocalGenerator`
and a few others.
* Greatly reduce using of `const char*` overloads for
`cmSystemTools::MakeDirectory` and `cmSystemTools::RelativePath`.
* Remove many redundant `c_str()` conversions throughout the code.
|
|
|
|
|
| |
- Use `std::move` while inserting temporary results into vectors.
- Change `push_back` to `emplace_back` where appropriate.
|
|\
| |
| |
| |
| |
| |
| |
| | |
c4dc6485 XL: Enable use of response files for includes and objects
e342e410 Makefile,Ninja: Use tool-specific response file flag for include dirs
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1691
|
| |
| |
| |
| |
| |
| |
| | |
When we use a response file for `-I` flags, not all compilers support
the `@<file>` syntax. Define `CMAKE_<LANG>_RESPONSE_FILE_FLAG` to
specify tool-specific flag, just as we do for linking already via
`CMAKE_<LANG>_RESPONSE_FILE_LINK_FLAG`.
|
| | |
|
|/
|
|
|
|
|
| |
Add the support of per-source property COMPILE_OPTIONS,
including generator expressions support.
Related: #17507
|
|
|
|
| |
Some are user-facing. Others are source comments.
|
|\
| |
| |
| |
| |
| |
| |
| | |
7ab9a625 Makefiles: Drop 'requires' step and its supporting infrastructure
5f2e2c38 Makefiles: Avoid nested make calls for Fortran module dependencies
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1523
|
| |
| |
| |
| |
| |
| |
| |
| | |
The 'requires' step was used to provide implicit dependencies between
the generated Fortran module files and a Fortran target that needs these
module files to ensure the correct compilation order. After recent
refactoring to resolve all dependencies explicitly through `.mod.stamp`
make targets, the separate 'requires' step is not needed anymore.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Makefiles generated by cmake use a series of nested calls to build
`*.provides.build` targets that are used when the 'requires' step is
needed. That leads to significant degradation of the build time for
incremental builds. Re-arrange dependencies to eliminate the nested
calls.
Explicit `.mod.stamp` targets introduced by this commit could lead to
situation when a stamp file always older than its dependency. This
happens during the incremental build when building of an updated Fortran
source produces a module file that has no differences from the stored
stamp file. In such case `cmake_copy_f90_mod` will be triggered on each
new build to compare a module file with the corresponding stamp file.
This behavior is expected and can not be changed without nested calls
that slow down the build. The copy-if-different check is much cheaper
than an entire nested make call.
|
| |
| |
| |
| | |
Fixes: #17542
|
| |
| |
| |
| |
| |
| | |
This allows users to specify different genex-based compile definitions for each file in a target.
Fixes: #17508
|
| |
| |
| |
| |
| |
| | |
Prepare to add generator expression support to more source properties.
Factor out some duplicated code into a helper to avoid further
duplication.
|
|/
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Signed-off-by: Matthias Maennich <matthias@maennich.net>
|
| |
|
|\
| |
| |
| |
| |
| |
| | |
3bbe95f5 Clean up iwyu code to not be one big if statement.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1247
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit changes the internal -E__run_iwyu to be -E__run_co_compile. This
is used for co-compile commands. These are tools that want to mirror the
compiler. For each compiler invocation the tool will be invoked first. This
started as a way to implement include what you use (iwyu), but has expanded
to include cpplint, cppcheck and others. Likely there will be more in the
future as well. This commit implements each one in its own function and
provides a way to add additional ones in the future with less work.
|
|/
|
|
|
|
| |
Changes done via `clang-tidy` with some manual fine-tuning
for the variable naming and `auto` type deduction
where appropriate.
|
|
|
|
|
|
| |
Create a `<LANG>_CPPCHECK` target property (initialized by a
`CMAKE_<LANG>_CPPCHECK` variable) to specify a `cppcheck` command line
to be run along with the compiler.
|
| |
|
|
|
|
|
|
|
|
| |
Add a `CUDA_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).
Fixes: #16953
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| | |
23691d78 CUDA: Allow sources to be compiled to .ptx files
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !725
|
| |
| |
| |
| |
| | |
When the target property `CUDA_PTX_COMPILATION` is enabled CUDA OBJECT
libraries will generate ptx files instead of object files.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | | |
cf320f7c Replace boolean `implib` parameters with enum
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !662
|
| |/
| |
| |
| |
| | |
Named enumeration values are much clearer at call sites and add more
type safety.
|
|/
|
|
|
|
| |
Move the logic to cmSystemTools to be shared among the generators.
Revise the implementation and add comments justifying each possible
source for a limit.
|
|
|
|
|
|
|
|
|
|
|
| |
The `WINDOWS_EXPORT_ALL_SYMBOLS` target property exports all symbols
found in object files explicitly given to the linker. However, the
linker may also find additional symbols in dependencies and copy them
into the linked binary (e.g. from `msvcrt.lib`). Provide a way to
export an explicit list of such symbols by adding a `.def` file as a
source file.
Fixes: #16473
|
|
|
|
|
|
|
| |
Use `cmGeneratorTarget::ModuleDefinitionInfo` to combine the
implementation of `WINDOWS_EXPORT_ALL_SYMBOLS` with that of using a
`.def` file as a source. Only one of these could be used within a
single target before anyway.
|
|
|
|
|
|
| |
Create a `ModuleDefinitionInfo` structure for each configuration of a
target to hold corresponding information about the selected module
definition file (`.def` source).
|
|
|
|
|
| |
If the property is explicitly set to a non-true value we should
not treat it as true.
|
|
|
|
|
|
| |
Create a `<LANG>_CPPLINT` target property (initialized by a
`CMAKE_<LANG>_CPPLINT` variable) to specify a `cpplint` style checker
command line to be run along with the compiler.
|
|
|
|
|
| |
Add a helper to cmCommonTargetGenerator instead of duplicating it
in cmMakefileTargetGenerator and cmNinjaTargetGenerator.
|
|\
| |
| |
| |
| |
| |
| | |
db61cd5d cmRulePlaceholderExpander: Remove unused member RuleLauncher
b7771078 Comment ExpandRuleVariables calls not preceded by launcher insertion
c58a5198 Makefile: Restore RULE_LAUNCH_COMPILE generation on compilation rules
|
| |
| |
| |
| |
| |
| |
| | |
Call sites of `ExpandRuleVariables` are now responsible for inserting
the `RULE_LAUNCH_{COMPILE,LINK,CUSTOM}` values in rule command lines.
Audit all call sites and add a comment to each one that does not insert
a launcher to explain why.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Refactoring in commit 425cd167 (cmLocalGenerator: Remove the launcher
from RuleVariables, 2016-10-09) accidentally broke Makefile generator
handling of `RULE_LAUNCH_COMPILE`. Responsibility moved from
`ExpandRuleVariables` to its call sites, and the Makefile generator call
site for compilations was not properly updated. Fix it now.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Change the default compile PDB file name for static libraries to match
the Visual Studio default of using the logical target name. This may be
incompatible with existing behavior but `COMPILE_PDB_NAME` documents
that the default is unspecified. Projects depending on a particular
name should set the property.
Closes: #16438
|
| | |
|
| |
| |
| |
| | |
We can consider PTX code to be a form of assembly.
|
| | |
|
| |
| |
| |
| |
| |
| | |
This allows users to specify different genex-based compile flags for
each file in a target, e.g. compiling just a single file with `Od/Ox` in
release builds on Visual Studio.
|
| |
| |
| |
| |
| | |
Include it in dependents which have previously relied on it
transitively.
|
| | |
|
| | |
|
|/ |
|