Wednesday, August 11, 2010

Using files from arago-oe-dev in arago overlay

While working with the Arago overlay I've been faced with the problem of needing "files" from the OpenEmbedded snapshot (arago-oe-dev) in my recipes that are contained in the Arago overlay. This can include .inc files or even files specified in the SRC_URI as file:// something. I've usually been able to avoid this issue in the first place by placing my recipe in the OpenEmbedded mainline (which is my preferred way to do things) or just amending a recipe in the OE mainline (i.e. adding an amend.inc file to the Arago overlay). However, recently I was confronted with a situation in which this wouldn't work.

The issue was that I had a recipe that does the following:
  1. It patches Qt/embedded to use library optimized to run on the ARM NEON.
  2. The library is NOT available for mass download (at least not at this time). Instead it is only available inside of the TI network.
The above conditions meant that I could not really put this recipe in the OE mainline because unless you were building from inside of the TI network it would fail to build. I also couldn't just amend the OE recipe in Arago because of the same reason, I would prevent the Arago mainline from being able to build Qt/e for anyone outside of TI. So what was my solution?

I decided to create a new recipe call qt4-embedded-blitrix_4.6.2.bb in the Arago overlay that would PROVIDES "qt4-embedded". Then, when building inside of TI I could add a conf/arago-bom.conf file (which is already included in local.conf) to my directory and specify PREFERRED_PROVIDER_qt4-embedded = "qt4-embedded-blitrix". In this way regular Qt builds would work but I could easily specify when to build the TI only version of Qt.

Here is where the file sharing comes in. Obviously I don't want to have to copy all of the files and .inc files from the OE snapshot into the Arago overlay. So I needed a way in my recipe to add the arago-oe-dev (OE snapshot) directory to my files path. Here is what I did:

  1. For .inc files I just made them relative paths which then causes bitbake to search the BBFILES paths for the first instance of the .inc file. So instead of saying "require qt4-embedded.inc" I instead said "require recipes/qt4/qt4-embedded.inc"
  2. For files in the SRC_URI I needed to add to my FILESPATHBASE variable the oe snapshot directory (arago-oe-dev). This would allow my recipe to find files in the arago-oe-dev directory as well as in the arago overlay directory. To do this I added FILESPATHBASE .= ":${OEBASE}/arago-oe-dev/recipes/qt4". Notice that I appended this path as I would want to get files from the Arago overlay first.
  3. Lastly, because my recipe had a different PN value (because of the name of the recipe file) I needed to add the original qt4-embedded directories to the list of places to search for these files. To do that I did FILESPATHPKG .= "qt4-embedded-${PV}:qt4-embedded". NOTE: depending on what files you are trying to pull you may need to prepend these values to make sure you get the right files. Or you could define the whole variable setting instead of appending or prepending. i.e. qt4-embedded:${PF}:${P}:${PN}:${BP}:${BPN}:qt4-embedded-${PV}:qt4-embedded:files:.:qt-${PV}
So basically the first several lines of my recipe looked like:

# Add the base qt4-embedded directories to the list of
# directories to be searched for files.
FILESPATHPKG .= ":qt4-embedded-${PV}:qt4-embedded"

# Add the arago-oe-dev directory to the base directories
# to search for files. This keeps us from having to
# copy files from the OE snapshot to the Arago overlay.
FILESPATHBASE .= ":${OEBASE}/arago-oe-dev/recipes/qt4"

# Using relative path here causes bitbake to search in
# BBPATH for the first instance of qt4-embedded.inc rather
# than just within the current directory.
require recipes/qt4/qt4-embedded.inc


Making the above modifications kept me from having to copy all the .inc files and the files from the SRC_URI into the Arago overlay.

NOTE: This recipe is not yet finished and I still have issues to resolve. This blog is just to serve as an example of how to use files from the OE mainline in the overlay without copying them.

Tuesday, August 3, 2010

distribute_license.bbclass

This blog post is going to be about the distribute_license.bbclass file that was added to openembedded mainline recently. It was added as commit id 5e75fa8c1b28055b610eb47ba5d3368a16810aa4 on July 30th 2010.

The reason I created this class was that while distributing images and software packages as part of an SDK I needed to also distribute a manifest of what software components were distributed and their licensing. However, some packages like liboil had "unknown" licensing defined in the ipk control file. This is because they don't have a standard license like GPL.

Instead packages like liboil have a COPYING or LICENSE or some other type of file in their soruces that indicates their licensing terms. The purpose of the distribute_license class is to take these files from the sources and copy them into the deploy direcgtory. Then the meta sdk package can include them for distribution. Thus packages like liboil can have their license set to "liboil" and users can look at the liboil directory in the deploy/licenses directory to find the license files for liboil.

By default this class will look only in the top-level source directory of a package for files matching the pattern COPYING* or LICENSE*. However, each package has the ability to define its own LICENSE_FILES pattern as well as LICENSE_SEARCH_DEPTH. This can be done using overrides such as:

LICENSE_FILES_liboil = "COPYING"
LICENSE_SEARCH_DEPTH_liboil = "2"

The reason for this is that packages may use a non-standard name for their license files. Thus it is useful to be able to change the search string. They may also not include the license file in the top-level directory, or sub-directories could have different licenses. This is why we allow varying search depth.

When the search depth is expanded past the top-level directory any matching licenses in a sub-directory will be placed in the ${DEPLOY_DIR}/licenses/${PN}/ relative path. That way it is clear what directory each license file corresponds to.