Merge pull request #401 from syntheticpp/win-network-path
[platform/upstream/ninja.git] / HACKING.md
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).
70
71 ### Test-driven development
72
73 Set your build command to
74
75     ./ninja ninja_test && ./ninja_test --gtest_filter=MyTest.Name
76
77 now you can repeatedly run that while developing until the tests pass
78 (I frequently set it as my compilation command in Emacs).  Remember to
79 build "all" before committing to verify the other source still works!
80
81 ## Testing performance impact of changes
82
83 If you have a Chrome build handy, it's a good test case.  Otherwise,
84 [the github downoads page](https://github.com/martine/ninja/downloads)
85 has a copy of the Chrome build files (and depfiles). You can untar
86 that, then run
87
88     path/to/my/ninja chrome
89
90 and compare that against a baseline Ninja.
91
92 There's a script at `misc/measure.py` that repeatedly runs a command like
93 the above (to address variance) and summarizes its runtime.  E.g.
94
95     path/to/misc/measure.py path/to/my/ninja chrome
96
97 For changing the depfile parser, you can also build `parser_perftest`
98 and run that directly on some representative input files.
99
100 ## Coding guidelines
101
102 Generally it's the [Google C++ coding style][], but in brief:
103
104 * Function name are camelcase.
105 * Member methods are camelcase, expect for trivial getters which are
106   underscore separated.
107 * Local variables are underscore separated.
108 * Member variables are underscore separated and suffixed by an extra
109   underscore.
110 * Two spaces indentation.
111 * Opening braces is at the end of line.
112 * Lines are 80 columns maximum.
113 * All source files should have the Google Inc. license header.
114
115 [Google C++ coding style]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
116
117 ## Documentation
118
119 ### Style guidelines
120
121 * Use `///` for doxygen.
122 * Use `\a` to refer to arguments.
123 * It's not necessary to document each argument, especially when they're
124   relatively self-evident (e.g. in `CanonicalizePath(string* path, string* err)`,
125   the arguments are hopefully obvious)
126
127 ### Building the manual
128
129     sudo apt-get install asciidoc --no-install-recommends
130     ./ninja manual
131
132 ### Building the code documentation
133
134     sudo apt-get install doxygen
135     ./ninja doxygen
136
137 ## Building for Windows
138
139 While developing, it's helpful to copy `ninja.exe` to another name like
140 `n.exe`; otherwise, rebuilds will be unable to write `ninja.exe` because
141 it's locked while in use.
142
143 ### Via Visual Studio
144
145 * Install Visual Studio (Express is fine), [Python for Windows][],
146   and (if making changes) googletest (see above instructions)
147 * In a Visual Studio command prompt: `python bootstrap.py`
148
149 [Python for Windows]: http://www.python.org/getit/windows/
150
151 ### Via mingw on Windows (not well supported)
152
153 * Install mingw, msys, and python
154 * In the mingw shell, put Python in your path, and `python bootstrap.py`
155 * To reconfigure, run `python configure.py`
156 * Remember to strip the resulting executable if size matters to you
157
158 ### Via mingw on Linux (not well supported)
159
160 * `sudo apt-get install gcc-mingw32 wine`
161 * `export CC=i586-mingw32msvc-cc CXX=i586-mingw32msvc-c++ AR=i586-mingw32msvc-ar`
162 * `./configure.py --platform=mingw --host=linux`
163 * Build `ninja.exe` using a Linux ninja binary: `/path/to/linux/ninja`
164 * Run: `./ninja.exe`  (implicitly runs through wine(!))
165