Adding include what you use instructions
This commit is contained in:
parent
3f10729d1b
commit
2824da034f
@ -27,6 +27,8 @@ Set the following properties or `CMAKE_*` initializer variables to the command l
|
||||
* `<LANG>_CPPLINT`
|
||||
* `<LANG>_INCLUDE_WHAT_YOU_USE`
|
||||
|
||||
## Clang tidy
|
||||
|
||||
Here is a simple example of using Clang-Tidy:
|
||||
|
||||
```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.
|
||||
|
||||
## 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
|
||||
|
||||
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):
|
||||
|
||||
```bash
|
||||
git ls-files -- '*.cpp' '*.h' | xargs clang-format -i -style=file
|
||||
git diff --exit-code --color
|
||||
```term
|
||||
gitbook $ git ls-files -- '*.cpp' '*.h' | xargs clang-format -i -style=file
|
||||
gitbook $ git diff --exit-code --color
|
||||
```
|
||||
|
@ -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:
|
||||
|
||||
```bash
|
||||
pip install cmake
|
||||
```term
|
||||
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.
|
||||
|
@ -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:
|
||||
|
||||
```bash
|
||||
git submodule add ../../owner/repo.git extern/repo
|
||||
```term
|
||||
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.
|
||||
|
Loading…
x
Reference in New Issue
Block a user