blob: 05fb69c67955fd8b7aa5acd76b8e7594670cc936 (
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
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
|
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://git.kernel.org/pub/scm/network/connman/connman.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
|
