forked from GunioRobot/speechcontrol
-
Notifications
You must be signed in to change notification settings - Fork 0
/
INSTALL
171 lines (125 loc) · 6.3 KB
/
INSTALL
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
Installing SpeechControl
=================
0. For the Impatient
# apt-get install cmake libqt4-dev libqtgstreamer-dev libpocketsphinx-dev libsphinxbase-dev libxdo-dev gstreamer0.10-pocketsphinx pkg-config libhunspell-dev libphonon-dev
$ mkdir build && cd build
$ cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Debug
$ make
You can run SpeechControl by invoking (while still in the build directory)
# src/app/speechcontrol
1. Required Packages
SpeechControl's core requires that you have the following packages installed:
* CMake 2.8
# apt-get install cmake
# apt-get install cmake-qt-gui # Install for a graphical interfaces
* Qt 4.7.2 (or higher), Phonon and its development files
# apt-get install libqt4-dev libphonon-dev
* Qt bindings to GStreamer (0.10) and its development files
# apt-get install libqtgstreamer-dev
* CMUSphinx's PocketSphinx speech recognition library and its development
files as well as the needed GStreamer elements
# apt-get install libpocketsphinx-dev libsphinxbase-dev gstreamer0.10-pocketsphinx
* XDO library and development files (for dictation functionality)
# apt-get install libxdo-dev
* Hunspell spell-checking development files and library (for spell-checking dictation input)
# apt-get install libhunspell-dev
* [Optional] Development files for kdelibs (4.7.2 or higher)
# apt-get install kdelibs5-dev
* [Optional] Python Scripting Support via PythonQt
# apt-get install libpythonqt-dev libpythonqt2.0
2. Configuration
In order to maintain cleanliness of the source code directory, we typically
manage all of CMake's routine work (as well as Make's) in a sub-directory.
For convenience's sake, we'll call it 'build'. So from the source code
directory; we make a new directory and go into it.
$ mkdir build && cd build
By default, SpeechControl builds with the following configuration values:
Configuration Value : Value
---------------------------------------------------------------------------
WITH_PYTHON_BINDINGS OFF (bindings for libspeechcontrol to Python)
WITH_TESTS OFF (initializes the test build system)
WITH_DOCS OFF (generates documentation about API)
WITH_KDE_SUPPORT OFF (builds KDE-specific bindings)
WITH_PLUGINS OFF (builds plug-ins)
These values only recognize the values 'ON' and 'OFF'. You can change these
values by doing the following:
$ cmake .. -DWITH_TESTS=OFF # disable tests
$ cmake .. -DWITH_KDE_SUPPORT=ON # enable KDE support and generates another
# target
It's possible to produce more specific information about your configuration
process and provide more direct information for troubleshooting. See the
"Testing" section for more information.
3. Building
To build SpeechControl, invoke the 'make' command from your specified
build directory.
$ make
$ make docs # Generates API documentation (if
# WITH_API_DOCS = ON)
$ make tests # Builds the tests (see 5. Testing)
It's possible to produce more concise dumps of information regarding your
build experience. See the "Testing" section for more information.
4. Running
From the build directory, you can invoke SpeechControl by:
* invoking the 'run' target of the build system or,
$ make run
* directly running the application or,
$ src/app/speechcontrol-frontend
It's possible to produce more verbose information during execution.
See the "Testing" section for more information. You can install SpeechControl
into your system by invoking:
# make install
and un-installing by invoking:
# make uninstall
5. Testing
You can test parts of SpeechControl and submit loads of information for
developers, packagers and future testers to determine what and where needs
to be tweaked so that SpeechControl can be properly built across multiple
systems. Part of the information sent back to the Synthetic Intellect Institute
development's CDash system looks like this (taken from JackyAlcine's system):
<Site BuildName="Linux-c++"
BuildStamp="20120220-2311-Continuous"
Name="tafc-desktop"
Generator="ctest-2.8.5"
CompilerName="/usr/bin/c++"
OSName="Linux"
Hostname="tafc-desktop"
OSRelease="3.0.0-16-generic"
OSVersion="#29-Ubuntu SMP Tue Feb 14 12:49:42 UTC 2012"
OSPlatform="i686"
Is64Bits="0"
VendorString="GenuineIntel"
VendorID="Intel Corporation"
FamilyID="6"
ModelID="15"
ProcessorCacheSize="1024"
NumberOfLogicalCPU="2"
NumberOfPhysicalCPU="2"
TotalVirtualMemory="3906"
TotalPhysicalMemory="3016"
LogicalProcessorsPerPhysical="1"
ProcessorClockFrequency="2200"
>
...
</Site>
Operating system information as well a bit of information about your
hardware are all collected with a log of the test suite output. Such
information is required in the nature of testing and CDash.
To provide us with even more useful information regarding your building
and testing experience (and it's recommended to do this if you build from
source), invoke the entire configuring, build, execution and test system.
Such information provides developers with valuable information. There's three
tags used for such purposes, but the other two ('Continuous' and 'Nightly')
are reserved for automated builds. Invoke the following:
$ make Experimental # invokes all of the Experimental commands.
CMake will then switch over to the CTest system and begin executing the tests
that are packaged along with the source code. There's typically two sectors of
tests, one of the library and another of the front-end's internal API. This
allows developers and testers to catch potential glitches and iron out ways to
prevent these issues from occurring again.
The output from the make command may be a bit verbose for some, so instead you
can do the following (from ${CMAKE_BINARY_DIR}/tests):
$ ctest
$ make tests # Builds the tests and then invokes 'ctest'.
This'll invoke the CTest system directly, however, the tests themselves have to
be built before you invoke this command. As a means of shorthand, you can just
use the 'tests' target to build and then execute all of the tests.