1
0
mirror of synced 2025-01-03 10:21:32 +01:00

Adding include what you use instructions

This commit is contained in:
Henry Fredrick Schreiner 2018-04-06 14:50:24 +02:00
parent 3f10729d1b
commit 2824da034f
3 changed files with 30 additions and 7 deletions

View File

@ -27,6 +27,8 @@ Set the following properties or `CMAKE_*` initializer variables to the command l
* `<LANG>_CPPLINT` * `<LANG>_CPPLINT`
* `<LANG>_INCLUDE_WHAT_YOU_USE` * `<LANG>_INCLUDE_WHAT_YOU_USE`
## Clang tidy
Here is a simple example of using Clang-Tidy: Here is a simple example of using Clang-Tidy:
```cmake ```cmake
@ -53,6 +55,27 @@ The `-fix` part is optional, and will modify your source files to try to fix the
If you want to explicitly use the target form to ensure you only call this on your local targets, you can set a variable (I usually chose `DO_CLANG_TIDY`) instead of the `CMAKE_CXX_CLANG_TIDY` variable, then add it to your target properties as you create them. If you want to explicitly use the target form to ensure you only call this on your local targets, you can set a variable (I usually chose `DO_CLANG_TIDY`) instead of the `CMAKE_CXX_CLANG_TIDY` variable, then add it to your target properties as you create them.
## Include what you use
This is an example for using include what you use. First, you'll need to have the tool, such as in a docker container:
```term
gitbook $ docker run --rm -it tuxity/include-what-you-use:clang_4.0
```
Then, you can pass this into your build without modifying the source:
```term
build # cmake .. -DCMAKE_CXX_INCLUDE_WHAT_YOU_USE=include-what-you-use
```
Finally, you can collect the output and apply the fixes:
```term
build # make 2> iwyu.out
build # fix_includes.py < iwyu.out
```
## Link what you use ## Link what you use
There is a boolean target property, `LINK_WHAT_YOU_USE`, that will check for extraneous files when linking. There is a boolean target property, `LINK_WHAT_YOU_USE`, that will check for extraneous files when linking.
@ -63,7 +86,7 @@ Clang-format doesn't really have an integration with CMake, unfortunately. You c
The following two line would do that in a git repository in bash (assuming you have a `.clang-format` file): The following two line would do that in a git repository in bash (assuming you have a `.clang-format` file):
```bash ```term
git ls-files -- '*.cpp' '*.h' | xargs clang-format -i -style=file gitbook $ git ls-files -- '*.cpp' '*.h' | xargs clang-format -i -style=file
git diff --exit-code --color gitbook $ git diff --exit-code --color
``` ```

View File

@ -35,8 +35,8 @@ You can also build CMake on any system, it's pretty easy, but binaries are faste
This is also provide as an official package, maintained by the authors of CMake at KitWare. It's a rather new method, and might fail on some systems (Alpine isn't supported last I checked, but that has CMake 3.8), but works really well when it works (like on Travis CI). If you have pip (Python's package installer), you can do: This is also provide as an official package, maintained by the authors of CMake at KitWare. It's a rather new method, and might fail on some systems (Alpine isn't supported last I checked, but that has CMake 3.8), but works really well when it works (like on Travis CI). If you have pip (Python's package installer), you can do:
```bash ```term
pip install cmake gitbook $ pip install cmake
``` ```
And as long as a binary exists for your system, you'll be up-and-running almost immediately. If a binary doesn't exist, it will try to use KitWare's `scikit-build` package to build, which currently can't be listed as a dependency in the packaging system, and might even require (an older) copy of CMake to build. So only use this system if binaries exist, which is most of the time. And as long as a binary exists for your system, you'll be up-and-running almost immediately. If a binary doesn't exist, it will try to use KitWare's `scikit-build` package to build, which currently can't be listed as a dependency in the packaging system, and might even require (an older) copy of CMake to build. So only use this system if binaries exist, which is most of the time.

View File

@ -2,8 +2,8 @@
If you want to add a Git repository on the same service (GitHub, GitLab, BitBucket, etc), the following is the correct Git command to set that up as a submodule in the `extern` directory: If you want to add a Git repository on the same service (GitHub, GitLab, BitBucket, etc), the following is the correct Git command to set that up as a submodule in the `extern` directory:
```bash ```term
git submodule add ../../owner/repo.git extern/repo gitbook $ git submodule add ../../owner/repo.git extern/repo
``` ```
The relative path to the repo is important; it allows you to keep the same access method (ssh or https) as the parent repository. This works very well in most ways. When you are inside the submodule, you can treat it just like a normal repo, and when you are in the parent repository, you can "add" to change the current commit pointer. The relative path to the repo is important; it allows you to keep the same access method (ssh or https) as the parent repository. This works very well in most ways. When you are inside the submodule, you can treat it just like a normal repo, and when you are in the parent repository, you can "add" to change the current commit pointer.