path: root/HACKING
diff options
authorZhang zhengguang <>2014-07-17 02:37:39 (GMT)
committerZhang zhengguang <>2014-07-17 02:37:39 (GMT)
commit1b9d0a62f59bb48c8deb2f0b98d9acdffdd9abe7 (patch)
tree6e991827d28537f7f40f20786c2354fd04a9fdad /HACKING
parentfbe905ab58ecc31fe64c410c5f580cadc30e7f04 (diff)
Imported Upstream version 1.24upstream/1.24
Diffstat (limited to 'HACKING')
1 files changed, 0 insertions, 144 deletions
diff --git a/HACKING b/HACKING
deleted file mode 100644
index 05fb69c..0000000
+++ /dev/null
@@ -1,144 +0,0 @@
-Hacking on Connection Manager
-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://
- # cd connman
- 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 "connmand". The "bootstrap-configure"
-automatically includes this option.
- Run daemon in foreground with debugging
- # sudo ./src/connmand -n -d 'plugins/*'
-The debugging option -d takes an argument. This argument can be a comma
-separated list of file names like 'plugins/wifi.c,plugins/ethernet.c' to
-enable debugs in these files. Simple glob style pattern matching is
-supported in this list.
-For production installations or distribution packaging it is important that
-the "--enable-maintainer-mode" option is NOT used.
-Some times it is important to restrict the available interfaces. For example
-in cases where testing happens over a network connection. The "-i" command
-line switch allows to specify a glob pattern for the interface names.
- Run daemon for wireless interfaces
- # sudo ./src/connmand -n -i wlan*
-Debugging the D-Bus interface during runtime
-Running the daemon with debugging information in the foreground is quite
-verbose and sometimes not really helpful. The "monitor-connman" script
-allows to monitor "PropertyChanged" D-Bus signals from various interfaces.
-Every "PropertyChanged" signal will generate a line of output. Some of them
-can get very complex. The first detail inside "{ ... }" is the interface
-name (without its service name prefix). The second detail inside "[ ... ]"
-is the object path. And after that it is followed by a key and value of
-the property that changed.
-Generating source code documentation
-The source code is annotated using the gtk-doc style documentation. This
-allows an easy way of generating API documentation. The "bootstrap-configure"
-script will use the "--enable-gtk-doc" configure to enable the generation of
-the documentation.
-To make the gtk-doc process work, the gtk-doc tools need to be installed.
-Every distribution should provide a package for this, but the naming of the
-package might be different:
- Debian
- # apt-get install gtk-doc-tools
- Ubuntu
- # apt-get install gtk-doc-utils
- Fedora
- # yum install gtk-doc
-In case "bootstrap-configure" is not used, the manual steps for generating
-the documentation files are like this:
- Configuring the repository
- # ./configure --enable-gtk-doc
- Generate the documentation
- # cd doc && make
- View documentation
- # firefox doc/html/index.html