Permalink
Cannot retrieve contributors at this time
Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign up| Hacking on oFono | |
| **************** | |
| Build tools requirements | |
| ======================== | |
| When building and testing directly from the repository it is important to | |
| have at least automake version 1.10 or later installed. All modern | |
| distributions should default to the latest version, but it seems that | |
| Debian's default is still an earlier version: | |
| Check version | |
| # dpkg -l '*automake*' | |
| Install new version | |
| # apt-get install automake1.10 | |
| # update-alternatives --config automake | |
| Working with the source code repository | |
| ======================================= | |
| The repository contains two extra scripts that accomplish the bootstrap | |
| process. One is called "bootstrap" which is the basic scripts that uses the | |
| autotools scripts to create the needed files for building and installing. | |
| It makes sure to call the right programs depending on the usage of shared or | |
| static libraries or translations etc. | |
| The second program is called "bootstrap-configure". This program will make | |
| sure to properly clean the repository, call the "bootstrap" script and then | |
| call configure with proper settings for development. It will use the best | |
| options and pass them over to configure. These options normally include | |
| the enabling the maintainer mode and the debugging features. | |
| So while in a normal source project the call "./configure ..." is used to | |
| configure the project with its settings like prefix and extra options. In | |
| case of bare repositories call "./bootstrap-configure" and it will bootstrap | |
| the repository and calls configure with all the correct options to make | |
| development easier. | |
| In case of preparing for a release with "make distcheck", don't use | |
| bootstrap-configure since it could export development specific settings. | |
| So the normal steps to checkout, build and install such a repository is | |
| like this: | |
| Checkout repository | |
| # git clone git://git.kernel.org/pub/scm/network/ofono/ofono.git | |
| # cd ofono | |
| Configure and build | |
| # ./bootstrap-configure | |
| # make | |
| Check installation | |
| # make install DESTDIR=$PWD/x | |
| # find x | |
| # rm -rf x | |
| Check distribution | |
| # make distcheck | |
| Final installation | |
| # sudo make install | |
| Remove autogenerated files | |
| # make maintainer-clean | |
| Running from within the source code repository | |
| ============================================== | |
| When using "./configure --enable-maintainer-mode" the automake scripts will | |
| use the plugins directly from within the repository. This removes the need | |
| to use "make install" when testing "ofonod". The "bootstrap-configure" | |
| automatically includes this option. | |
| Copy configuration file which specifies the required security policies | |
| # sudo cp ./src/ofono.conf /etc/dbus-1/system.d/ | |
| Run daemon in foreground with debugging | |
| # sudo ./src/ofonod -n -d 'plugins/*' | |
| For production installations or distribution packaging it is important that | |
| the "--enable-maintainer-mode" option is NOT used. | |
| Note multiple arguments to -d can be specified, colon, comma or space | |
| separated. The arguments are relative source code filenames for which | |
| debugging output should be enabled; output shell-style globs are | |
| accepted (e.g.: 'plugins/*:src/main.c'). | |
| Other debugging settings that can be toggled: | |
| - Environment variable OFONO_AT_DEBUG (set to 1): enable AT commands | |
| debugging | |
| Submitting patches | |
| ================== | |
| If you fixed a bug or you want to add support for something, patches are | |
| welcome! In order to ease the inclusion of your patch, it's important to follow | |
| some rules, otherwise it will likely be rejected by maintainers: | |
| 1) Do *not* add "Signed-off-by" lines in your commit messages. oFono does not | |
| use them, so including them is actually an error. | |
| 2) Be sure to follow the coding style rules of oFono. They are listed in | |
| doc/coding-style.txt. | |
| 3) Split your patch according to the top-level directories. E.g.: if you added | |
| a feature that touches files under 'include/', 'src/' and 'drivers/' | |
| directories, split in three separated patches, taking care not to | |
| break compilation. | |
| 4) Submit patches using git send-email to ofono@ofono.org |