9. Customize to you needs

This chapter describes one way to customize the openembedded repository to your needs. The idea is to provide an additional packages repository which is used to define the additional stuff.

9.1 Adding another package repository

We will explain that using an example directory myoe/packages, which is then similarly used as the org.openembedded.dev/packages repository. To inform bitbake about this new repository you have to extend the conf/local.conf file. The new BBFILES line(s) are e.g.

BBFILES := "${HOME}/dev/oe/org.openembedded.dev/packages/*/*.bb"
BBFILES += "${HOME}/myoe/packages/*/*.bb"
        

The next bitbake run will parse the dev/oe/org.openembedded.dev packages as well as all packages found in myoe/packages.

9.2 Adding a new machine

Unfortunately this can only be done in org.openembedded.dev/conf/machine for now. The easiest way to do is to copy a similar machine configuration and modify to your needs.

As an example I will build a machine based on my c7x0 (zaurus) and name that my1stmach.

1. A cd org.openembedded.dev/conf/machine; cp c7x0.conf my1stmach.conf followed by changing the content of my1stmach.conf to your needs (Description, ...).
2. A cd org.openembedded.dev/conf/machine; cp zaurus-clamshell.conf my1stmach-common.conf provides a copy of the common used zaurus features. This common definitions are included in my1stmach.conf (content of that to be changed to use my1stmach-common.conf) and are only helpfull, if you want to use a group of similar devices (e.g. different flash sizes).

Note that this is all to be done so far. All machine relevant dependencies should be defined here now.

Important Note!
As this is done inside the org.openembedded.dev dir, you should make a copy of your changes before calling monotone to resync your repository, as you ma loose your changes.

9.3 Adding a new distro

Is done the same way as the machine.

As an example I will build a distro based on generic and name that my1stdistro.

1. A cd org.openembedded.dev/conf/distro; cp generic.conf my1stdistro.conf followed by changing the content of my1stdistro.conf to your needs (Description, ...).

Note that this is all to be done so far. All distro relevant dependencies should be defined here now. Especially BOOTSTRAP_EXTRA_(R)DEPENDS are defined / added in here to extend the bootstrap-images content.

Important Note!
As this is done inside the org.openembedded.dev dir, you should make a copy of your changes before calling monotone to resync your repository, as you ma loose your changes.

9.4 Adding a new bootstrap-image

As we may want to modify lots of stuff here and use this to explain the above created additional package repository we do a deep copy of the related packages.

1. Create a dir myoe/packages/meta (as used for this kind of bb files in org.openembedded.dev as well.
2. cp org.openembedded.dev/packages/meta/task-bootstrap.bb myoe/packages/meta/mytask-bootstrap.bb
   will provide a copy of the original task-bootstrap.bb package. You can now modify this new mytask-bootstrap.bb file to your needs (e.g. add or remove packages, ...)
3. cp org.openembedded.dev/packages/meta/bootstrap-image.bb myoe/packages/meta/mybootstrap-image.bb
   will provide a copy of the original bootstrap-iage.bb package. You can now modify this new mybootstrap-image.bb file to your needs. At least we have to change the dependency to task-bootstrap-bb dependency. Follow the hints below.
   • Change the entry IMAGE_BASENAME
     The result look like

     export IMAGE_BASENAME = "mybootstrap-image"
                                             
     

   • Change the entry IPKG_INSTALL
     The result look like

     export IPKG_INSTALL = "mytask-bootstrap"
                                             
     

     This entry defines, which packages are installed into the images root file system (and thus the image itself).
   • Change the entry DEPENDS
     The result look like

     DEPENDS = "mytask-bootstrap"
                                             
     

   • May be you want to remove the FEED_URIS stuff (if you do not want to work using a openzaurus ipkg based image).

9.5 Build the above mentioned bootstrap-image

This section last but not least describes how you can build your first self designed bootstrap-image. To be able to do so, we start to define a new build target as we want to use the machine / distro definition above as well.

To prepare the build follow the hints below.

• Create a build directory
  A mkdir whereEver/build-my1stmachine will do so.
• Provide an environment script to prepare your build dir.
  The easyset way may be to copy an already existing one ( more info see here ). A cp env-whatever env-my1stmachine will do so.
  Change the following entries
  • OEBUILD : The build dir location

    OEBUILD=$OESYS2/build-my1stmachine
                                    
    

  • PS1 : The Prompt

    PS1="[OE-MY1ST]$PS1"
                                    
    

  You can now change into your build environment calling . env-my1stmachine.
• Provide a conf/local.conf.
  The easyset way may be to copy an already existing one ( more info see here ). A cp -a ../build-whatever/conf . will do so.
  Change the following entries
  • BBFILES : Add your packages repository

    BBFILES := "${HOME}/dev/oe/org.openembedded.dev/packages/*/*.bb"
    BBFILES += "${HOME}/myoe/packages/*/*.bb"
                                    
    

  • MACHINE : Provide your newly created machine target

    MACHINE = "my1stmach"
                                    
    

  • DISTRO : Provide your newly created distro target

    DISTRO = "my1stdistro"
                                    
    

You can now build your self designed bootstrap-image. A
bitbake mybootstrap-image
will start the build process. Some hours later you will probably have a freshly created bootstrap image named tmp/deploy/images/mybootstrap-image_xxx.gz.

9.6 Example : Adding a new package (from existing sources)

You can also add new packages if not already provided easily.

This section describes the integration of the schedutils package, which was needed during some tests. As this package is not "configured", but provides a "static" makefile, this is a good example how to handle that kind of stuff.

The following list describes the steps I needed to do to get the package building for the correct target.

1. Locate the sources package
   Here $DEBIAN_MIRROR is always a good idea.
2. Create a package subdir in your myoe/packages dir and provide a schedutils_1.4.0.bb file (e.g. copied from psmisc package) matching the actual souces version.
3. Manipulate the bb file
   The result looks like shown below.

   LICENSE = "GPL"
   DESCRIPTION = "schedutils tools : realtime process manipulation tools"
   SECTION = "base"
   PRIORITY = "optional"
   MAINTAINER = "Werner Schulte <w1 at schulte-ac.de>"
   PR = "r0"
   
   SRC_URI = "${DEBIAN_MIRROR}/main/s/schedutils/schedutils_${PV}.orig.tar.gz \
           file://schedutils_make.patch;patch=1;pnum=1"
   
   S = "${WORKDIR}/schedutils-${PV}"
   
   inherit autotools
   
   PACKAGES = "${PN}"
   
   FILES_${PN} = "/usr/local/bin/*"
   # RDEPENDS_${PN} = ""
   
   python do_package_prepend() {
           destdir = "%s/usr/local/bin" % (bb.data.expand('${D}', d))
           bb.mkdirhier(destdir)
   }
                   
   

   The following list describes the main entries.
   • SRC_URI
     Provides the path to the sources package. Note that in my case I had to add a patchfile which corrects some entries in the static Makefile. More Info can be found in subsection Makefile.
   • FILES_${PN}
     Describes the list of files to be installed (here we have to provide this, as the Makefile installs into the non standard dir /usr/local/bin).
   • python do_package_prepend()
     As the static Makefile wants to install its content to / (using install) we did already patch the file, but still hav the problem, that the install process wants to create a directory in the images dir. To avoid this, whe have to add (prepend) the package method. You can see, that this is python code. A subdir to the image dir is created named usr/local/dir.
4. Try bitbake schedutils in your target
   Note, that you will need several iterations to get the package be build. The main reason here was, that the package uses a static Makefile not prepared to be used in a CROSS environment. See more information below.

Preparing the Makefile

This subsection describes the changes I had to do on the Makefile and the way to create and provide an appropriate patch.

• Unpack the sources tgz or the cvs dir into your patch dir and create a copy of the resulting dir named xxx_orig.
• Edit the non _orig's Makefile.
• Remove (or comment) the CC entry to force CROSS usage
• Remove (or comment) the CFLAGS entry to force bitbake CFLAGS usage.
  Note, that this may be wrong, when non standard entries need to be provided. Change the CFLAGS to e.g. CYFLAGS entry in the complete Makefile in this case.
• Added $(DESTDIR) to the PRFIX variable to cause make to install binaries to the ${D} dir instead to /
• Potentially you do not want to install something like includ or man pages.
  remove that targets from Makefile then.
• Create a patch calling diff -Naur xxx xxx_orig > xxx_make.patch where xxx is your packages dir name.
• Copy that patch to myoe/packages/schedutils/schedutils dir (matching the SRC_URI's patch entry described above ).

Done that changes, you have the chance to build your new package.