|
| 1 | +## Basic overview |
| 2 | + |
| 3 | +`./configure.py` generates the `build.ninja` files used to build |
| 4 | +ninja. It accepts various flags to adjust build parameters. |
| 5 | + |
| 6 | +The primary build target of interest is `ninja`, but when hacking on |
| 7 | +Ninja your changes should be testable so it's more useful to build |
| 8 | +and run `ninja_test` when developing. |
| 9 | + |
| 10 | +(`./bootstrap.py` creates a bootstrap `ninja` and runs the above |
| 11 | +process; it's only necessary to run if you don't have a copy of |
| 12 | +`ninja` to build with.) |
| 13 | + |
| 14 | +### Adjusting build flags |
| 15 | + |
| 16 | +Build in "debug" mode while developing (disables optimizations and builds |
| 17 | +way faster on Windows): |
| 18 | + |
| 19 | + ./configure.py --debug |
| 20 | + |
| 21 | +To use clang, set `CXX`: |
| 22 | + |
| 23 | + CXX=clang++ ./configure.py |
| 24 | + |
| 25 | +## How to successfully make changes to Ninja |
| 26 | + |
| 27 | +Github pull requests are convenient for me to merge (I can just click |
| 28 | +a button and it's all handled server-side), but I'm also comfortable |
| 29 | +accepting pre-github git patches (via `send-email` etc.). |
| 30 | + |
| 31 | +Good pull requests have all of these attributes: |
| 32 | + |
| 33 | +* Are scoped to one specific issue |
| 34 | +* Include a test to demonstrate their correctness |
| 35 | +* Update the docs where relevant |
| 36 | +* Match the Ninja coding style (see below) |
| 37 | +* Don't include a mess of "oops, fix typo" commits |
| 38 | + |
| 39 | +These are typically merged without hesitation. If a change is lacking |
| 40 | +any of the above I usually will ask you to fix it, though there are |
| 41 | +obvious exceptions (fixing typos in comments don't need tests). |
| 42 | + |
| 43 | +I am very wary of changes that increase the complexity of Ninja (in |
| 44 | +particular, new build file syntax or command-line flags) or increase |
| 45 | +the maintenance burden of Ninja. Ninja is already successfully in use |
| 46 | +by hundreds of developers for large projects and it already achieves |
| 47 | +(most of) the goals I set out for it to do. It's probably best to |
| 48 | +discuss new feature ideas on the mailing list before I shoot down your |
| 49 | +patch. |
| 50 | + |
| 51 | +## Testing |
| 52 | + |
| 53 | +### Installing gtest |
| 54 | + |
| 55 | +The `ninja_test` binary, containing all the tests, depends on the |
| 56 | +googletest (gtest) library. |
| 57 | + |
| 58 | +* On older Ubuntus it'll install as libraries into `/usr/lib`: |
| 59 | + |
| 60 | + apt-get install libgtest |
| 61 | + |
| 62 | +* On newer Ubuntus it's only distributed as source |
| 63 | + |
| 64 | + apt-get install libgtest-dev |
| 65 | + ./configure --with-gtest=/usr/src/gtest |
| 66 | + |
| 67 | +* Otherwise you need to download it, unpack it, and pass |
| 68 | + `--with-gtest` to `configure.py`. Get it from [its downloads |
| 69 | + page](http://code.google.com/p/googletest/downloads/list); [this |
| 70 | + direct download link might work |
| 71 | + too](http://googletest.googlecode.com/files/gtest-1.6.0.zip). |
| 72 | + |
| 73 | +### Test-driven development |
| 74 | + |
| 75 | +Set your build command to |
| 76 | + |
| 77 | + ./ninja ninja_test && ./ninja_test --gtest_filter=MyTest.Name |
| 78 | + |
| 79 | +now you can repeatedly run that while developing until the tests pass |
| 80 | +(I frequently set it as my compilation command in Emacs). Remember to |
| 81 | +build "all" before committing to verify the other source still works! |
| 82 | + |
| 83 | +## Testing performance impact of changes |
| 84 | + |
| 85 | +If you have a Chrome build handy, it's a good test case. Otherwise, |
| 86 | +[the github downoads page](https://github.com/martine/ninja/downloads) |
| 87 | +has a copy of the Chrome build files (and depfiles). You can untar |
| 88 | +that, then run |
| 89 | + |
| 90 | + path/to/my/ninja chrome |
| 91 | + |
| 92 | +and compare that against a baseline Ninja. |
| 93 | + |
| 94 | +There's a script at `misc/measure.py` that repeatedly runs a command like |
| 95 | +the above (to address variance) and summarizes its runtime. E.g. |
| 96 | + |
| 97 | + path/to/misc/measure.py path/to/my/ninja chrome |
| 98 | + |
| 99 | +For changing the depfile parser, you can also build `parser_perftest` |
| 100 | +and run that directly on some representative input files. |
| 101 | + |
| 102 | +## Coding guidelines |
| 103 | + |
| 104 | +Generally it's the [Google C++ coding style][], but in brief: |
| 105 | + |
| 106 | +* Function name are camelcase. |
| 107 | +* Member methods are camelcase, expect for trivial getters which are |
| 108 | + underscore separated. |
| 109 | +* Local variables are underscore separated. |
| 110 | +* Member variables are underscore separated and suffixed by an extra |
| 111 | + underscore. |
| 112 | +* Two spaces indentation. |
| 113 | +* Opening braces is at the end of line. |
| 114 | +* Lines are 80 columns maximum. |
| 115 | +* All source files should have the Google Inc. license header. |
| 116 | + |
| 117 | +[Google C++ coding style]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml |
| 118 | + |
| 119 | +## Documentation |
| 120 | + |
| 121 | +### Style guidelines |
| 122 | + |
| 123 | +* Use `///` for doxygen. |
| 124 | +* Use `\a` to refer to arguments. |
| 125 | +* It's not necessary to document each argument, especially when they're |
| 126 | + relatively self-evident (e.g. in `CanonicalizePath(string* path, string* err)`, |
| 127 | + the arguments are hopefully obvious) |
| 128 | + |
| 129 | +### Building the manual |
| 130 | + |
| 131 | + sudo apt-get install asciidoc --no-install-recommends |
| 132 | + ./ninja manual |
| 133 | + |
| 134 | +### Building the code documentation |
| 135 | + |
| 136 | + sudo apt-get install doxygen |
| 137 | + ./ninja doxygen |
| 138 | + |
| 139 | +## Building for Windows |
| 140 | + |
| 141 | +While developing, it's helpful to copy `ninja.exe` to another name like |
| 142 | +`n.exe`; otherwise, rebuilds will be unable to write `ninja.exe` because |
| 143 | +it's locked while in use. |
| 144 | + |
| 145 | +### Via Visual Studio |
| 146 | + |
| 147 | +* Install Visual Studio (Express is fine), [Python for Windows][], |
| 148 | + and (if making changes) googletest (see above instructions) |
| 149 | +* In a Visual Studio command prompt: `python bootstrap.py` |
| 150 | + |
| 151 | +[Python for Windows]: http://www.python.org/getit/windows/ |
| 152 | + |
| 153 | +### Via mingw on Windows (not well supported) |
| 154 | + |
| 155 | +* Install mingw, msys, and python |
| 156 | +* In the mingw shell, put Python in your path, and `python bootstrap.py` |
| 157 | +* To reconfigure, run `python configure.py` |
| 158 | +* Remember to strip the resulting executable if size matters to you |
| 159 | + |
| 160 | +### Via mingw on Linux (not well supported) |
| 161 | + |
| 162 | +* `sudo apt-get install gcc-mingw32 wine` |
| 163 | +* `export CC=i586-mingw32msvc-cc CXX=i586-mingw32msvc-c++ AR=i586-mingw32msvc-ar` |
| 164 | +* `./configure.py --platform=mingw --host=linux` |
| 165 | +* Build `ninja.exe` using a Linux ninja binary: `/path/to/linux/ninja` |
| 166 | +* Run: `./ninja.exe` (implicitly runs through wine(!)) |
| 167 | + |
0 commit comments