open-lighting/README.developer at master · mlba-team/open-lighting · GitHub

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
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
                            Developer Information
###############################################################################

This file provides some information for developers looking to submit patches to
OLA. The first section contains some general notes, and the latter
sections address particular languages.


General
===============================================================================

Code Reviews
------------

To have patches reviewed please push your changes to a Google Code Repo, or
github. Then open an issue with 'Type-Review' at
http://code.google.com/p/linux-lighting/issues/list

If you're using Google Code please enable comments on the repo. Under
Administer -> Source check:
  Enable code reviews
  Allow non-members to review code

Licensing
---------

Think carefully about the license for each file. Code to be used by clients
(./ola , ./python) should be under the LGPL, so that it may be used in
commercial projects.

Plugins and code used solely in olad should be under the GPL.

scripts/enforce_licence.py will look for a LICENCE file in each directory, and
ensure that all source files in the directory ( & subdirectories) start with
the LICENCE. You can pass --fix to automatically add the licence.

Unittests
---------

Unittests are *highly* encouraged. At the very least please make sure any
changes don't break the tests.

The tests are performed with `make check` in the root ola directory. The same
command can be run within a sub directory to only run a particular set of
tests.


C++
===============================================================================

The bulk of OLA code is written in C++. This includes the daemon olad, and
plugins.

http://www.opendmx.net/index.php/OLA_developer_info describes many of the
underlying classes used.

Endian Issues
-------------

Be aware that OLA runs on big endian systems. When dealing with wire formats
always use the functions in include/ola/network/NetworkUtils.h to convert or
use the BigEndianOutputStream to manage this automatically for you.

Non x86 platforms
-----------------

OLA also runs on more than just x86. Some platforms like ARM can't de-reference
pointers which aren't aligned.

For example:

struct f {
  uint8_t value1;
  uint16_t value2;
} __attribute__((packed));

struct f foo = {1, 2};
uint16_t *ptr = &foo.value2;
// Bug! Will not be true on all platforms.
if (*ptr == 2)

http://www.aleph1.co.uk/chapter-10-arm-structured-alignment-faq has a good
explanation.


Style / Coding Standards
------------------------

We use the Google C++ Style Guide:
  http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml

Please run the cpplint.py script on all files before requesting a review.

cpplint.py can be downloaded here:
  http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py

Run it with:
   --filter=-legal/copyright,-readability/streams

Race Conditions
---------------

If possible, code should be tested with slower machines (embedded platforms,
virtual machines etc.). This has discovered race conditions in the past.

Valgrind
--------

All code must be tested with valgrind to ensure it doesn't leak memory.

Coverage (gcov)
---------------

To enable the coverage tools, you need lcov and gcov installed. To enable run
./configure --enable-gcov and then build as normal.

To generate the HTML pages run:

  mkdir /tmp/lcov
  tmpdir=`mktemp -d /tmp/lcov.XXXXXX`
  coverage="${tmpdir}/coverage.info"
  lcov --capture --directory ./ --output-file $coverage
  genhtml $coverage --output-directory /tmp/lcov


Java
===============================================================================

An experimental Java API is provided.

Style / Coding Standards
------------------------

Please follow the Sun Java style guide.


Javascript
===============================================================================

Javascript is used for the olad web UI. Instructions for building the
javascript can be found in javascript/README.

Closure Compiler
----------------

The closure compiler catches many errors. The javascript code should build
cleanly.

Style / Coding Standards
------------------------

We use the Google Javascript style guide:
  http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml

A javascript linter can be downloaded from:
  http://code.google.com/closure/utilities/docs/linter_howto.html

Please make sure all Javascript code is lint clean.


Python
===============================================================================

Python is used for tools like the RDM responder tests and the device model
collector. To enable these a OLA Python API is provided.

Style / Coding Standards
------------------------

We use the Google Python style guide:
  http://google-styleguide.googlecode.com/svn/trunk/pyguide.html

However we deviate from the standard and use 2 space indents, so it's
consistent with the C++ code.