3 # Copyright 2004,2007,2008 Free Software Foundation, Inc.
5 # This file is part of GNU Radio
7 # GNU Radio is free software; you can redistribute it and/or modify
8 # it under the terms of the GNU General Public License as published by
9 # the Free Software Foundation; either version 3, or (at your option)
12 # GNU Radio is distributed in the hope that it will be useful,
13 # but WITHOUT ANY WARRANTY; without even the implied warranty of
14 # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
15 # GNU General Public License for more details.
17 # You should have received a copy of the GNU General Public License
18 # along with GNU Radio; see the file COPYING. If not, write to
19 # the Free Software Foundation, Inc., 51 Franklin Street,
20 # Boston, MA 02110-1301, USA.
23 Random notes on coding conventions, some explanations about why things
24 aren't done differently, etc, etc,
29 Until boost 1.35 or later is common in distributions, you'll need to
30 build boost from source yourself. See README.building-boost.
32 Also, when running make distcheck you'll need to provide the
33 DISTCHECK_CONFIGURE_FLAGS. E.g.,
35 $ make distcheck DISTCHECK_CONFIGURE_FLAGS=--with-boost=/opt/boost_1_36_0
40 GNU Radio is now a hybrid system. Some parts of the system are built
41 in C++ and some of it in Python. In general, prefer Python to C++.
42 Signal processing primitives are still built in C++ for performance.
44 It is no longer possible to build user applications entirely in C++.
45 Essential parts of the runtime system have been moved into Python.
50 In the cleanup process, I considered putting everything in the
51 gnuradio namespace and dropping the Gr|gr prefix. In fact, I think
52 it's probably the right idea, but when I tested it out, I ran into
53 problems with SWIG's handling of namespaces. Bottom line, SWIG
54 (1.3.21) got confused and generated bad code when I started playing
55 around with namespaces in a not particularly convoluted way. I saw
56 problems using the boost::shared_ptr template in combination with
57 classes defined in the gnuradio namespace. It wasn't pretty...
62 Death to CamelCaseNames! We've returned to a kinder, gentler era.
63 We're now using the "STL style" naming convention with a couple of
64 modifications since we're not using namespaces.
66 With the exception of macros and other constant values, all
67 identifiers shall be lower case with words_separated_like_this.
69 Macros and constant values (e.g., enumerated values,
70 static const int FOO = 23) shall be in UPPER_CASE.
75 All globally visible names (types, functions, variables, consts, etc)
76 shall begin with a "package prefix", followed by an '_'. The bulk of
77 the code in GNU Radio logically belongs to the "gr" package, hence
78 names look like gr_open_file (...).
80 Large coherent bodies of code may use other package prefixes, but
81 let's try to keep them to a well thought out list. See the list
86 These are the current package prefixes:
90 gri_ Implementation primitives. Sometimes we
91 have both a gr_<foo> and a gri_<foo>. In that case,
92 gr_<foo> would be derived from gr_block and gri_<foo>
93 would be the low level guts of the function.
95 atsc_ Code related to the Advanced Television
96 Standards Committee HDTV implementation
98 usrp_ Universal Software Radio Peripheral
100 qa_ Quality Assurance. Test code.
103 ** Class data members (instance variables)
105 All class data members shall begin with d_<foo>.
107 The big win is when you're staring at a block of code it's obvious
108 which of the things being assigned to persist outside of the block.
109 This also keeps you from having to be creative with parameter names
110 for methods and constructors. You just use the same name as the
111 instance variable, without the d_.
113 class gr_wonderfulness {
115 double d_wonderfulness_factor;
118 gr_wonderfulness (std::string name, double wonderfulness_factor)
119 : d_name (name), d_wonderfulness_factor (wonderfulness_factor)
127 ** Class static data members (class variables)
129 All class static data members shall begin with s_<foo>.
134 Each significant class shall be contained in it's own file. The
135 declaration of class gr_foo shall be in gr_foo.h, the definition in
142 Strongly consider using the boost smart pointer templates, scoped_ptr
143 and shared_ptr. scoped_ptr should be used for locals that contain
144 pointers to objects that we need to delete when we exit the current
145 scope. shared_ptr implements transparent reference counting and is a
146 major win. You never have to worry about calling delete. The right
149 See http://www.boost.org/libs/smart_ptr/smart_ptr.htm
154 Build unit tests for everything non-trivial and run them after every
155 change. Check out Extreme Programming:
156 http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap
158 Unit tests should also be written for all examples. This should kill
159 off the bit rot we've been plagued with.
163 For C++ we're using the cppunit framework. cppunit has its bad
164 smells, but it's mostly workable. http://cppunit.sf.net
166 Currently each directory <dirname> contains files qa_<dirname>.{h,cc}
167 that bring together all the qa_<foo> test suites in the directory.
168 We ought to be able to automate this without too much trouble.
170 The directory gnuradio-core/src/tests contains programs that run
171 the tests. test_all runs all of the registered C++ unit tests.
173 As far as I can tell, the cppunit TestFactoryRegistry maybe able to be
174 tricked into doing what we want. As is, I don't think it's enough by
175 itself, since there's nothing dragging the qa* files out of the
176 library and into the program. I haven't tested out this idea.
180 We use the standard unittest package for unit testing of Python code.
183 * Subversion line ending styles
185 All text files in the tree should have the subversion property
186 'svn:eol-style' set to 'native', with the following exceptions:
190 gr-howto-write-a-block/config/*.m4
191 gr-howto-write-a-block/configure.ac
193 The easiest way to ensure this is to add or edit the following lines in
194 your svn client configuration file (~/.subversion/config):
196 enable-auto-props=yes
199 *.c = svn:eol-style=native
200 *.cc = svn:eol-style=native
201 *.i = svn:eol-style=native
202 *.h = svn:eol-style=native
203 *.am = svn:eol-style=native
204 *.py = svn:eol-style=native
205 *.ac = svn:eol-style=LF
206 *.m4 = svn:eol-style=LF
210 ccache, a compiler cache, can really speed up your builds.
211 See http://ccache.samba.org/
213 Be sure to create links for gcc and g++
216 * Standard command line options
218 When writing programs that are executable from the command line,
219 please follow these guidelines for command line argument names (short
220 and long) and types of the arguments. We list them below using the
221 Python optparse syntax. In general, the default value should be coded
222 into the help string using the "... [default=%default]" syntax.
224 ** Mandatory options by gr_block
228 Any program using a USRP source (usrp.source_*) shall include:
230 add_option("", "--which-usrp", type="intx", default=0,
231 help="select which USRP to use [default=%default]")
233 add_option("-R", "--rx-subdev-spec", type="subdev", default=(0, 0),
234 help="select USRP Rx side A or B [default=A]")
236 You are free to change the default if it makes sense in your application.
241 Any program using a USRP sink (usrp.sink_*) shall include:
243 add_option("", "--which-usrp", type="intx", default=0,
244 help="select which USRP to use [default=%default]")
246 add_option("-T", "--tx-subdev-spec", type="subdev", default=(0, 0),
247 help="select USRP Tx side A or B [default=A]")
249 You are free to change the default if it makes sense in your application.
254 Any program using an audio source shall include:
256 add_option("-I", "--audio-input", type="string", default="",
257 help="pcm input device name. E.g., hw:0,0 or /dev/dsp")
259 The default must be "". This allows an audio module-dependent default
260 to be specified in the user preferences file.
265 add_option("-O", "--audio-output", type="string", default="",
266 help="pcm output device name. E.g., hw:0,0 or /dev/dsp")
268 The default must be "". This allows an audio module-dependent default
269 to be specified in the user preferences file.
272 ** Standard options names by parameter
274 Whenever you want an integer, use the "intx" type. This allows the
275 user to input decimal, hex or octal numbers. E.g., 10, 012, 0xa.
277 Whenever you want a float, use the "eng_float" type. This allows the
278 user to input numbers with SI suffixes. E.g, 10000, 10k, 10M, 10m, 92.1M
280 If your program allows the user to specify values for any of the
281 following parameters, please use these options to specify them:
284 To specify a frequency (typically an RF center frequency) use:
286 add_option("-f", "--freq", type="eng_float", default=<your-default-here>,
287 help="set frequency to FREQ [default=%default]")
290 To specify a decimation factor use:
292 add_option("-d", "--decim", type="intx", default=<your-default-here>,
293 help="set decimation rate to DECIM [default=%default]")
296 To specify an interpolation factor use:
298 add_option("-i", "--interp", type="intx", default=<your-default-here>,
299 help="set interpolation rate to INTERP [default=%default]")
302 To specify a gain setting use:
304 add_option("-g", "--gain", type="eng_float", default=<your-default-here>,
305 help="set gain in dB [default=%default]")
308 If your application specifies both a tx and an rx gain, use:
310 add_option("", "--rx-gain", type="eng_float", default=<your-default-here>,
311 help="set receive gain in dB [default=%default]")
313 add_option("", "--tx-gain", type="eng_float", default=<your-default-here>,
314 help="set transmit gain in dB [default=%default]")
317 To specify the number of channels of something use:
319 add_option("-n", "--nchannels", type="intx", default=1,
320 help="specify number of channels [default=%default]")
323 To specify an output filename use:
325 add_option("-o", "--output-filename", type="string", default=<your-default-here>,
326 help="specify output-filename [default=%default]")
329 To specify a rate use:
331 add_option("-r", "--bit-rate", type="eng_float", default=<your-default-here>,
332 help="specify bit-rate [default=%default]")
335 add_option("-r", "--sample-rate", type="eng_float", default=<your-default-here>,
336 help="specify sample-rate [default=%default]")
339 If your application has a verbose option, use:
341 add_option('-v', '--verbose', action="store_true", default=False,
342 help="verbose output")
345 If your application allows the user to specify the "fast USB" options, use:
347 add_option("", "--fusb-block-size", type="intx", default=0,
348 help="specify fast usb block size [default=%default]")
350 add_option("", "--fusb-nblocks", type="intx", default=0,
351 help="specify number of fast usb blocks [default=%default]")