summaryrefslogtreecommitdiffstats
path: root/HACKING
blob: 92cdf68262ecdfbc049e88160a2f9c7086122d7f (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
Adjusting build flags:
  CFLAGS=-O3 ./configure.py
  and rebuild.

Test-driven development:
  Set your build command to
    ./ninja ninja_test && ./ninja_test --gtest_filter=MyTest.Name
  now you can repeatedly run that while developing until the tests pass.
  Remember to build "all" before committing to verify the other source
  still works!

Testing performance impact of changes:
  If you have a Chrome build handy, it's a good test case.
  Otherwise, https://github.com/martine/ninja/downloads has a copy of
  the Chrome build files (and depfiles). You can untar that, then run
  "ninja chrome".  I often do something like:
    (for i in `seq 5`; do time -p ninja chrome) 2>&1 | grep real > old
    (for i in `seq 5`; do time -p ninja-new chrome) 2>&1 | grep real > new
  and then compare those two lists of timings either by eye or with R.

  For changing the depfile parser, you can also build 'parser_perftest'
  and run that directly on some representative input files.

Coding guidelines:
- Function name are camelcase.
- Member methods are camelcase, expect for trivial getters which are
  underscore separated.
- Local variables are underscore separated.
- Member variables are underscore separated and suffixed by an extra underscore.
- Two spaces indentation.
- Opening braces is at the end of line.
- Lines are 80 columns maximum.
- All source files should have the Google Inc. license header.
- Also follow this style:
  http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml

Documentation guidelines:
- Use /// for doxygen.
- Use \a to refer to arguments.
- It's not necessary to document each argument, especially when they're
  relatively self-evident (e.g. in CanonicalizePath(string* path, string* err),
  the arguments are hopefully obvious)

Generating the manual:
  sudo apt-get install asciidoc --no-install-recommends
  ./ninja manual

Windows development on Linux (this is kind of hacky right now):
- Get the gtest source, unpack it into your source dir
- sudo apt-get install gcc-mingw32 wine
- export CC=i586-mingw32msvc-cc CXX=i586-mingw32msvc-c++ AR=i586-mingw32msvc-ar
- ./configure.py --platform=mingw --host=linux --with-gtest=gtest-1.6.0
- Build ninja: /path/to/linux/ninja
- Run: ./ninja.exe  (implicitly runs through wine(!))

Windows development on Windows:
- install mingw, msys, and python
- in the mingw shell, put Python in your path, and: python bootstrap.py
- to reconfigure, run 'python configure.py'
- remember to strip the resulting executable if size matters to you
- you'll need to rename ninja.exe into my-ninja.exe during development,
  otherwise ninja won't be able to overwrite itself when building

Using clang:
- Enable colors manually:
  CXX='/path/to/llvm/Release+Asserts/bin/clang++ -fcolor-diagnostics' ./configure.py