Building a custom package

Да се разработи Linux/OSGi базирана разпределена сензорна система за събиране на метеорологични данни, състояща се от сензорна, сервизна и приложна части. Съставните части на системата да са гъвкаво конфигурируеми и с възможност да работят върху различни платформи. Функционалността, свързана с всеки отделен сензор да е йерархично разпределена и да може да се преконфигурира по време на работа на системата. Всеки отделен сензор или група, както и поддържаните от тях услуги да се регистрират в системата автоматично след инсталирането и пускането им в действие. Интерфейса към потребителя и персонала по поддръжката да е унифициран и достъпен чрез специализирано приложение или Интернет. Да се дефинират критерии за оценка на системата и съставните и части. Да се извърши анализ на възможни решения съобразно дефинираните критерии.

Building a custom package

Postby mladen » Wed Aug 17, 2011 4:59 pm

To add package you need to write a recipe for it. Writing a recipe means creating a .bb file which sets various variables. Recipes usually use names of the form: Simple directory structure of package “mladen” could be created as is presented below:
Code: Select all
mkdir -p /angstrom/sources/local/recipes/mladen
mkdir -p /angstrom/sources/local/recipes/mladen/files

We are going to use as example,, its code is presented below:
Code: Select all
DESCRIPTION = "Mladen Application"
PR = "r0"

SRC_URI = "file://mladen.c \


do_compile() {
    ${CC} ${CFLAGS} ${LDFLAGS} ${WORKDIR}/*.c -o mladen

do_install() {
    install -m 0755 -d ${D}${bindir} ${D}${docdir}/mladen
    install -m 0755 ${S}/mladen ${D}${bindir}
    install -m 0644 ${WORKDIR}/README.txt ${D}${docdir}/mladen

To understand what is described above, use the following table that summaries the main variables often used in the recipes:
PN: The package name. Determined from the recipe filename - everything up until the first underscore is considered to be the package name. For the recipe the PN variable would be set to "sample-recipe".

PV: The package version. Determined from the recipe filename - everything between the first underscore and the final .bb is considered to be the package version. For the recipe the PV variable would be set to "1.0.0".

P: The package name and versions separated by a hyphen. For the recipe the P variable would be set to "sample-recipe-1.0.0".
PR: The package release. This should be explicitly set in the recipe, if not set it defaults to "r0".

WORKDIR: The working directory is where the source code is extracted, where files (other than patches) are copied, and where the logs and installation files are created. WORKDIR is initialized to PN-PV-PR, so for example recipe, the value of WORKDIR would be set to "sample-recipe_1.0.0-r0" (assuming that the recipe set PR to "r0")

S: This is the unpacked source directory.
Bitbake expects to find the extracted source for a package in a directory called packagename-version in the WORKDIR directory. This is the directory which it will change to before patching, compiling and installing the package.
For example, let's assume we have a package recipe called and we are extracting the source from the sample-1.0.0.tar.gz file. Bitbake expects the source to end up in a directory called sample-1.0.0 within the WORKDIR.
If the source does not end up in this directory, then bitbake needs to be told this by explicitly setting S.

D: This is the destination directory. It specifies where your package should be installed. The packaging system takes the contents of this directory and packages it for installation on the target.
The directory structure beneath D should reflect where the package files are to end up in the target system. For example, if a package file is intended to end up in /usr/bin on the target system, the recipe should install the files into ${D}/usr/bin.
It is considered poor practice to directly specify /usr/bin. The build system provides a set of variables that you should use instead (see table in Appendix). So for the example above, the proper installation directory specification would be ${D}${bindir}

DESCRIPTION: Specifies the text that will be displayed by the package management system to describe what the package is.

MANTAINER: The name of the mantainer and usually an e-mail address

LICENSE: The package license name

DEPENDS: If there were dependencies on any other packages to build or run, we would list them here.

SRC_URI: Tell the build system where to find source code for the package

FILES_${PN}: Describes the list of files to be installed

RDEPENDS: A list of recommended packages to be installed

The example recipe code above specified the name of the source files „mladen.c“ and „README.txt“ with a file:// prefix, this is the way you must do it, if the source code is located in the local file system.
„mladen.c“ is simple C program presented below
Code: Select all
#include <stdio.h>

int main(int argc, char** argv)
    int i;
    for (i=0;i<10;i++) {
        printf("Hello world!\nFrom the new Mladen application\n\n");
    return 0;

and README.txt contains simple package documentation
Code: Select all
This is just a doc file in the Mladen application.

To build a “mladen” package, simply type the following at a console prompt. You don't need to cd into the package directory to do this. BitBake knows where to look for recipes and it will automatically find and build the “mladen” package.
Code: Select all
bitbake mladen
Posts: 10
Joined: Tue Feb 22, 2011 5:16 pm

Return to OSGi based sensor network

Who is online

Users browsing this forum: No registered users and 1 guest