summaryrefslogtreecommitdiff
path: root/sdk-multiplatform-deployment-using-cerbero.md
blob: 3b93d5ecb5e28b98b61e4d62446eccc6a7a50f7a (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
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
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
# Multiplatform deployment using Cerbero

Cerbero is the build and packaging system used to construct the
GStreamer SDK. It uses “recipe” files that indicate how to build
particular projects, and on what other projects they depend.
Moreover, the built projects can be combined into packages for
distribution. These packages are, depending on the target platform,
Windows or OS X installers or Linux packages.

To use Cerbero to build and package your application, you just need to
add a recipe explaining how to build you application and make it depend
on the `gstreamer-sdk` project. Then Cerbero can take care of building
your application and its dependencies and package them all together.

Read [Building from source using
Cerbero](Building%2Bfrom%2Bsource%2Busing%2BCerbero.html) to learn how
to install and use Cerbero.

At this point, after reading the Build from source section in [Building
from source using
Cerbero](Building%2Bfrom%2Bsource%2Busing%2BCerbero.html), you should be
able to build the GStreamer SDK from source and are ready to create
recipe and package files for your application.

In the Cerbero installation directory you will find the
`cerbero-uninstalled` script. Execute it without parameters to see the
list of commands it accepts:

``` bash
./cerbero-uninstalled
```

# Adding a recipe for your application

The first step is to create an empty recipe that you can then tailor to
your needs:

``` bash
./cerbero-uninstalled add-recipe my-app 1.0
```

This will create an initial recipe file in `recipes/my-app.recipe`,
which contains the smallest necessary recipe. This file is a Python
script; set the following attributes to describe your application:

Attribute Name

Description

Required

Example

`name`

The recipe name.

Yes

*name = 'my-app'*

`version`

The software version.

Yes

*version = '1.0'*

`licenses`

A list of licenses of the software (see `cerbero/enums.py:License` for
allowed licenses).

Yes

*licenses = \[License.LGPLv2Plus\]*

`deps`

A list of build dependencies of the software as recipe names.

No

*deps = \['other', 'recipe', 'names'\]*

`platform_deps`

Platform specific build dependencies (see `cerbero/enums.py:Platform`
for allowed platforms).

No

*platform\_deps = {Platform.LINUX: \['some-recipe'\], Platform.WINDOWS:
\['another-recipe'\]}*

`remotes`

A dictionary specifying the git remote urls where sources are pulled
from.

No

*remotes = {'origin': '<git://somewhere>'}*

`commit`

The git commit, tag or branch to use, defaulting to "sdk-*`version`*"*.*

No

*commit = 'my-app-branch'*

`config_sh`

Used to select the configuration script.

No

*config\_sh = 'autoreconf -fiv && sh ./configure'*

`configure_options`

Additional options that should be passed to the `configure` script.

No

*configure\_options = '--enable-something'*

`use_system_libs`

Whether to use system provided libs.

No

*use\_system\_libs = True*

`btype`

The build type (see `cerbero/build/build.py:BuildType` for allowed build
types).

No

*btype = BuildType.CUSTOM*

`stype`

The source type (see `cerbero/build/source.py:SourceType` for allowed
source types).

No

*stype = SourceType.CUSTOM*

`files_category`

A list of files that should be shipped with packages including this
recipe *category*. See below for more details.

Cerbero comes with some predefined categories that should be used if the
files being installed match a category criteria.

The predefined categories are:

`libs` (for libraries), `bins` (for binaries), `devel` (for development
files - header, pkgconfig files, etc), `python` (for python files) and
`lang` (for language files).

Note that for the `bins` and `libs` categories there is no need to
specify the files extensions as Cerbero will do it for you.

Yes\*

*files\_bins = \['some-binary'\]*

*files\_libs = \['libsomelib'\]*

*files\_devel = \['include/something'\] files\_python =
\['site-packages/some/pythonfile%(pext)s'\]*

*files\_lang = \['foo'\]*

`platform_files_category`

Same as *`files_category`* but for platform specific files.

No

*platform\_files\_some\_category = {Platform.LINUX: \['/some/file'\]}*

\* At least one “files” category should be set.

Apart from the attributes listed above, it is also possible to override
some Recipe methods. For example the `prepare` method can be overridden
to do anything before the software is built, or the `install` and
`post_install` methods for overriding what should be done during or
after installation. Take a look at the existing recipes in
`cerbero/recipes` for example.

Alternatively, you can pass some options to cerbero-uninstalled so some
of these attributes are already set for you. For
example:

```
./cerbero-uninstalled add-recipe --licenses "LGPL" --deps "glib,gtk+" --origin "git://git.my-app.com" --commit "git-commit-to-use" my-app 1.0
```

See `./cerbero-uninstalled add-recipe -h` for help.

As an example, this is the recipe used to build the Snappy media player:

```
class Recipe(recipe.Recipe):
    name = 'snappy'
    version = '0.2+git'
    licenses = [License.GPLv2Plus]
    config_sh = 'autoreconf -fiv && sh ./configure'
    deps = ['glib', 'gstreamer', 'gst-plugins-base', 'clutter', 'clutter-gst']
    platform_deps = { Platform.LINUX: ['libXtst'] }
    use_system_libs = True
    remotes = {'upstream': 'git://git.gnome.org/snappy'}

    files_bins = ['snappy']
    files_data = ['share/snappy']

    def prepare(self):
        if self.config.target_platform == Platform.LINUX:
            self.configure_options += ' --enable-dbus' 
```

Cerbero gets the software sources to build from a GIT repository, which
is specified via the `git_root` configuration variable from the Cerbero
configuration file (see the "Build from software" section in [Installing
on Linux](Installing%2Bon%2BLinux.html)) and can be overridden by the
`remotes` attribute inside the recipes (if setting the `origin` remote).
In this case where no “commit” attribute is specified, Cerbero will use
the commit named “sdk-0.2+git” from the GIT repository when building
Snappy.

Once the recipe is ready, instruct Cerbero to build it:

``` bash
./cerbero-uninstalled build my-app
```

# Adding a package for you software

To distribute your software with the SDK it is necessary to put it into
a package or installer, depending on the target platform. This is done
by selecting the files that should be included. To add a package you
have to create a package file in `cerbero/packages`. The package files
are Python scripts too and there are already many examples of package
files in `cerbero/packages`.

Now, to create an empty package, do:

``` bash
./cerbero-uninstalled add-package my-app 1.0
```

This will create an initial package file in `packages/my-app.package`.

The following Package attributes are used to describe your package:

**Attribute Name**

**Description**

**Required**

**Example**

`name`

The package name.

Yes

*name = 'my-app'*

`shortdesc`

A short description of the package.

No

*shortdesc = 'some-short-desc'*

`longdesc`

A long description of the package.

No

*longdesc = 'Some Longer Description'*

`codename`

The release codename.

No

*codename = 'MyAppReleaseName'*

`vendor`

Vendor for this package.

No

*vendor = 'MyCompany'*

`url`

The package url

No

*url = 'http://www.my-app.com'*

`version`

The package version.

Yes

*version = '1.0'*

`license`

The package license (see `cerbero/enums.py:License` for allowed
licenses).

Yes

*license = License.LGPLv2Plus*

`uuid`

The package unique id

Yes

*uuid = '6cd161c2-4535-411f-8287-e8f6a892f853'*

`deps`

A list of package dependencies as package names.

No

*deps = \['other', 'package', 'names'\]*

`sys_deps`

The system dependencies for this package.

No

*sys\_deps= {Distro.DEBIAN: \['python'\]}*

`files`

A list of files included in the **runtime** package in the form
*“recipe\_name:category1:category2:...”*

If the recipe category is omitted, all categories are included.

Yes\*

*files = \['my-app'\]*

*files = \['my-app:category1'\]*

`files_devel`

A list of files included in the **devel** package in the form
*“recipe\_name:category1:category2:...”*

Yes\*

*files\_devel = \['my-app:category\_devel'\]*

`platform_files`

Same as *files* but allowing to specify different files for different
platforms.

Yes\*

*platform\_files = {Platform.WINDOWS:
\['my-app:windows\_only\_category'\]}*

`platform_files_devel`

Same as *files\_devel* but allowing to specify different files for
different platforms.

Yes\*

*platform\_files\_devel = {Platform.WINDOWS:
\['my-app:windows\_only\_category\_devel'\]}*

\* At least one of the “files” attributes should be set.

Alternatively you can also pass some options to `cerbero-uninstalled`,
for
example:

``` bash
./cerbero-uninstalled add-package my-app 1.0 --license "LGPL" --codename MyApp --vendor MyAppVendor --url "http://www.my-app.com" --files=my-app:bins:libs --files-devel=my-app:devel --platform-files=linux:my-app:linux_specific --platform-files-devel=linux:my-app:linux_specific_devel,windows:my-app:windows_specific_devel --deps base-system --includes gstreamer-core
```

See `./cerbero-uninstalled add-package -h` for help.

As an example, this is the package file that is used for packaging the
`gstreamer-core` package:

```
class Package(package.Package):
    name = 'gstreamer-codecs'
    shortdesc = 'GStreamer codecs'
    version = '2012.5'
    codename = 'Amazon'
    url = "http://www.gstreamer.com"
    license = License.LGPL
    vendor = 'GStreamer Project'
    uuid = '6cd161c2-4535-411f-8287-e8f6a892f853'
    deps = ['gstreamer-core']

    files = ['flac:libs',
            'jasper:libs', 'libkate:libs',
            'libogg:libs', 'schroedinger:libs', 'speex:libs',
            'libtheora:libs', 'libvorbis:libs', 'wavpack:libs', 'libvpx:libs',
            'taglib:libs',
            'gst-plugins-base:codecs', 'gst-plugins-good:codecs',
            'gst-plugins-bad:codecs', 'gst-plugins-ugly:codecs']
    files_devel = ['gst-plugins-base-static:codecs_devel',
            'gst-plugins-good-static:codecs_devel',
            'gst-plugins-bad-static:codecs_devel',
            'gst-plugins-ugly-static:codecs_devel']
    platform_files = {
            Platform.LINUX: ['libdv:libs'],
            Platform.DARWIN: ['libdv:libs']
    } 
```

At this point you have two main options: you could either have a single
package that contains everything your software needs, or depend on a
shared version of the SDK.

### Having a private version of the SDK

To have a private version of the SDK included in a single package you
don't have to add the `deps` variable to the package file but instead
list all files you need in the `files` variables. If you decide to go
this road you must make sure that you use a different prefix than the
GStreamer SDK in the Cerbero configuration file, otherwise your package
will have file conflicts with the GStreamer SDK.

### Having a shared version of the SDK

If you decide to use a shared version of the SDK you can create a
package file like the other package files in the GStreamer SDK. Just
list all packages you need in the `deps` variable and put the files your
software needs inside the `files` variables. When building a package
this way you must make sure that you use the same prefix and
packages\_prefix as the ones in your Cerbero configuration file.

Finally, build your package by using:

``` bash
./cerbero-uninstalled package your-package 
```

Where `your-package` is the name of the `.package` file that you created
in the `packages` directory. This command will build your software and
all its dependencies, and then make individual packages for them (both
the dependencies and your software). The resulting files will be in the
current working directory.