| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Run the `clang-format.bash` script to update our C and C++ code to a new
include order `.clang-format`. Use `clang-format` version 6.0.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The set of compile flags used for a target's C and C++ sources is based
on the linker language. By default this is always the C++ flags if any
C++ sources appear in the target, and otherwise the C flags. Therefore
we can define the `COMPILE_LANGUAGE` generator expression in
`INCLUDE_DIRECTORIES` to match the selected language.
This is not exactly the same as for other generators, but is the best VS
and Xcode can do. It is also sufficient for many use cases since the
set of include directories for C and C++ is frequently similar but may
be distinct from those for other languages like CUDA.
Fixes: #17435
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Run the `Utilities/Scripts/clang-format.bash` script to update
all our C++ code to a new style defined by `.clang-format`.
Use `clang-format` version 3.8.
* 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sort include directives within each block (separated by a blank line) in
lexicographic order (except to prioritize `sys/types.h` first). First
run `clang-format` with the config file:
---
SortIncludes: false
...
Commit the result temporarily. Then run `clang-format` again with:
---
SortIncludes: true
IncludeCategories:
- Regex: 'sys/types.h'
Priority: -1
...
Commit the result temporarily. Start a new branch and cherry-pick the
second commit. Manually resolve conflicts to preserve indentation of
re-ordered includes. This cleans up the include ordering without
changing any other style.
Use the following command to run `clang-format`:
$ git ls-files -z -- \
'*.c' '*.cc' '*.cpp' '*.cxx' '*.h' '*.hh' '*.hpp' '*.hxx' |
egrep -z -v '(Lexer|Parser|ParserHelper)\.' |
egrep -z -v '^Source/cm_sha2' |
egrep -z -v '^Source/(kwsys|CursesDialog/form)/' |
egrep -z -v '^Utilities/(KW|cm).*/' |
egrep -z -v '^Tests/Module/GenerateExportHeader' |
egrep -z -v '^Tests/RunCMake/CommandLine/cmake_depends/test_UTF-16LE.h' |
xargs -0 clang-format -i
This selects source files that do not come from a third-party.
Inspired-by: Daniel Pfeifer <daniel@pfeifer-mail.de>
|
|
|
|
| |
Issue an error if this is encountered by an IDE generator.
|
|
|
|
|
|
| |
The include_directories() and add_compile_options() commands
should not append to the corresponding target property for IMPORTED
targets. This is already the case for add_definitions().
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Treat paths which are relative and which contain a generator
expression which is not at the beginning as relative to the
source directory.
This matches the behavior of paths which are relative but contain
no generator expression at all.
Previously this would generate a relative path with the IMPORTED
target on export(), which would be a reported as a non-existent
path on import. If used directly in the buildsystem, it would be
reported as a relative path, which is also an error. There is no
need for a policy in this case.
|
|
|
|
|
|
|
|
| |
Code such as
target_include_directories(foo PRIVATE ${items})
should not work or break based on whether items is defined or not.
|
|
|
|
|
|
|
| |
Change the unit test introduced in commit 24dcf0c0 (Make sure
generator expressions can be used with target_include_directories.,
2013-01-16) to not use the expression, but still test the appropriate
code.
|
|
|
|
|
|
|
|
|
| |
This reverts commit 0b92602b816e2584db3781b120a1e5200da72ada.
Conflicts:
Source/cmGeneratorExpressionEvaluator.cxx
Tests/CMakeCommands/target_compile_definitions/CMakeLists.txt
Tests/CMakeCommands/target_include_directories/CMakeLists.txt
|
| |
|
|
|
|
|
|
| |
This is both a short form of using a TARGET_DEFINED expression
together with a TARGET_PROPERTY definition, and a way to strip
non-target content from interface properties when exporting.
|
|
|
|
|
| |
This way we can add handling of relative/absolute paths and of
-D in compile definitions.
|
| |
|
|\
| |
| |
| |
| |
| | |
b98d14d Disallow porcelain to populate includes and defines of IMPORTED targets.
48a4cf2 Revert "Allow target_link_libraries with IMPORTED targets."
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
With similar reasoning to the parent commit, as downstreams, we can't
determine what $<CONFIG> generator expressions would be appropriate.
Upstream would have populated the INTERFACE_INCLUDE_DIRECTORIES with
config-specific generator expressions, possibly appropriate for
their DEBUG_CONFIGURATIONS. In theory, if we would add include
directories for a DEBUG intent, we would have to match the upstream
configurations for that.
Rather than attempting to discover the appropriate configurations
at this time, simplify the feature instead. The use of IMPORTED targets
with these commands could still be added in the future if targets
would export their DEBUG_CONFIGURATIONS somehow.
|
|/
|
|
|
| |
Handle the case that a generator expression is used before treating
a non-target as an error.
|
|
This is a convenience API to populate the corresponding properties.
|