-
Notifications
You must be signed in to change notification settings - Fork 6
/
BUILD.txt
201 lines (156 loc) · 8.7 KB
/
BUILD.txt
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
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
Gmu Music Player
Copyright (c) 2006-2016 Johannes Heimansberg
http://wej.k.vu/
1. Build Instructions
To compile Gmu you will need a build environment for the desired target.
Such an environment typically consists of a compiler and additional
libraries. It is called a 'tool chain'.
Gmu has been tested with GNU make and both GCC and clang, but other C
compilers should work as well. It should be possible to build and run
Gmu on any POSIX compliant system.
Gmu needs a few libraries:
Gmu core:
- libSDL
- libpthread
- optional: sqlite3 (for the media library)
Gmu SDL frontend
- libSDL
- libSDL_image
- libSDL_gfx (optional but highly recommended)
Additional libraries are required for the decoder plugins, e.g. the
Tremor library is required by the Ogg Vorbis decoder plugin and
libmpg123 is required by the MP3 decoder plugin.
Since Gmu 0.10.0 the build process has been simplified, by including a
configure script (not autotools based). With this script the previously
required manual creation of .mk config files (see below) is no longer
required, although it is still possible to do that. The configure script
tries to figure out which components are available on the system and
enables/disables optional parts of Gmu accordingly. The configure script
also understands a couple of command line options for configuring various
things manually. Run ./configure --help for an overview of available options.
The syntax is similar to the typical autoconf based configure script.
Example:
To configure Gmu with the media library feature enabled and the ModPlug
decoder disabled, one could run the configure script like so:
$ ./configure --enable=medialib --disable=modplug-decoder
Most optional features are enabled automatically as soon as the configure
detects all necessary dependencies. The only exception is the media library
which is currently disabled, since it is not yet fully implemented. This
default will change as soon as the media library is usable from all
major frontends.
Sometimes you might want to disable certain features, even if you meet
all the requirements. For example you might want to disable some of the
module decoders, since they all support most module formats, but vary in
playback accuracy and CPU usage.
Besides the --enable and --disable flags, there are a couple of other flags
that can be used to tell configure where to find certain files or to
configure other settings:
--includes
This can be used to specify additional include paths for header files.
--libs
This can be used to specify additional library search paths.
--sdk-path
This can be used to specify the tool chain's base directory.
--target-device
This can be used to specify the desired target device. The target
device selection is used to build Gmu with hardware specifig features.
This usually includes things like display backlight control and audio
mixer settings. For a hardware target "dingux" the hardware specific
code could be found in the src directory in hw_dingux.h and hw_dingux.c.
If no target device is speficied, the default generic "unknown" target
is used.
After a successful configure run Gmu can be built with make, e.g.:
$ make -j5
Another example (for building Gmu with the OpenWRT Zipit Z2 toolchain):
$ CFLAGS="-I/opt/openwrt-libs-includes_bleeding-edge/usr/include/ncursesw -I/opt/openwrt-libs-includes_bleeding-edge/usr/include/SDL -I/opt/openwrt-libs-includes_bleeding-edge/usr/include" \
LFLAGS="-L/opt/openwrt-libs-includes_bleeding-edge/lib -L/opt/openwrt-libs-includes_bleeding-edge/usr/lib" \
CC=arm-openwrt-linux-muslgnueabi-gcc ./configure \
--sdk-path=/opt/OpenWrt-Toolchain-pxa_gcc-5.3.0_musl-1.1.14_eabi.Linux-x86_64/toolchain-arm_xscale_gcc-5.3.0_musl-1.1.14_eabi/ \
--target-device=zipit-z2
$ make
Prior to Gmu 0.10.0 it was necessary to create an .mk config file manually
or use one of the included files for building for a specific target.
These files are still included for a couple of supported target devices
and can still be used for compiling for these machines in addition to
the configure way described above.
For each target there is a .mk file which contains the configuration.
Please note that it might be necessary to modify the .mk files to match
your configuration. If you have installed your toolchain in a different
location, you need to modify those paths accordingly.
To build Gmu for target 'dingux' you would invoke make this way:
$ make TARGET=dingux
Calling make without specifying a target causes the Makefile to build with a
default configuration, which results in a Gmu binary compatible with your
build machine (typically x86 or AMD64 Linux).
To build Gmu's main binary only, you can do so by using the make target 'gmu':
$ make TARGET=dingux gmu.bin
To build the decoders only, you would use the 'decoders' target instead, or
when you want to build a specific decoder only, you would tell make to build
only that decoder, e.g. when you want to build the vorbis decoder only, you
would use 'decoders/vorbis.so' as your target.
1.1 Makefile targets
There are some Makefile targets, that might be of interest.
1.1.1 install:
The install target installs Gmu on a system. It understands the
environment variables DESTDIR and PREFIX. PREFIX should be used for
telling 'make' where Gmu should be installed on the target system. It is
usually set to something like "/usr" or "/usr/local".
DESTDIR on the other hand specifies a temporary location where the files
are actually copied to. When you just want to install Gmu on the system,
you do not need to set DESTDIR at all. If you, on the other hand, want
to create an installable package, you probably want to use it.
Example:
$ make DESTDIR=/tmp/foo PREFIX=/usr install
This will install Gmu as if it was installed under /usr, but actually
copy its files to /tmp/foo/usr.
1.1.2 distbin:
The distbin target can be used to create a zip file containing everything
that is needed to run Gmu. When extracting the zip file, Gmu can be run
from the directory contained in the zip file without any further
installation. The distbin target is usually used for devices like the
GP2X, the GP2X Wiz or the Caanoo, where the user downoads programs as
zip files and just extracts them on his SD card.
1.1.3 dist:
The dist target creates a .tar.gz archive containing everything to build
Gmu from source.
2. Adding a new target
When using the configure script, most of what follows (2.1) is irrelevant,
since it can be configured with arguments to configure. Hardware specific
stuff still needs to be done manually. See 2.2 for that.
2.1 Adding a new target the old way
To make Gmu compile for a new target platform, there are a few steps that need
to be followed.
First you need to create a .mk file for that target. Let's call it new_target.mk.
The easiest way of creating that file is to copy the existing unknown.mk to
new_target.mk.
Next you need to edit that file. The paths/names to the compiler and the libs
need to be adjusted to match your toolchain's configuration.
You can also adjust the DECODERS_TO_BUILD line, depending on which libraries
are available in your toolchain. To remove the dependency on libSDL_gfx you
can set SDLFE_WITHOUT_SDL_GFX=1. This will disable cover image support.
2.2 Hardware specific code
Depending on the device you are trying to run Gmu on, you might want to add
device specific code for screen/backlight control and/or the audio mixer
to control the volume with the device's hardware mixer. Both things are
optional and aren't needed for all devices.
You need to create two files hw_new_target.h and hw_new_target.c. These
files consist of hardware specific things. Again, the easiest way of creating
those files is copying them. Copy hw_unknown.h to hw_new_target.h and
hw_unknown.c to hw_new_target.c. You can make adjustments to those files later,
if you want/need to.
That should be it. You should now be able to build Gmu to run on your new target
device. Of course hardware specific things, like the ability to turn of the
display do not work in that stage. For these things, you need to modify
the hw_new_target.c/h files.
You probably also want to adjust the button mappings to match your new device.
This can be done through config files. You do not need to recompile Gmu for
changing the button configuration.
2.3 Static build
By default, Gmu's plugins are built as external loadable plugins. It is
also possible to build Gmu as one static binary with all plugins built-in.
This can be useful for platforms where you are unable to dynamically load
shared objects (e.g. if you are forced to statically link the binary due
to a very old userland like on the GP2X with the default firmware).
To compile statically set STATIC=1. The unknown.mk target has been prepared
to support such a static build. Have a look at that file to get an idea how
to adapt your own .mk target file for static building.