Developer Workflow Improvements: Difference between revisions

From Yocto Project
Jump to navigationJump to search
Line 45: Line 45:
# Although generated recipe will likely build, it may need some tweaks to some of the tasks (e.g. configure, compile, install)
# Although generated recipe will likely build, it may need some tweaks to some of the tasks (e.g. configure, compile, install)
# Once app is building, iteratvely develop using devtool (or Eclipse) to deploy and test on target  
# Once app is building, iteratvely develop using devtool (or Eclipse) to deploy and test on target  
# Check in "completed" code and recipe
# Add recipe to new or existing layer
# Build new image including new layer and recipe and validate
# Build new image including new layer and recipe and validate



Revision as of 19:49, 3 January 2017

Back to Yocto Project Main Page

Introduction

The page describes how new tools such as Cross Platform Support (CROPS), Extensible SDK (eSDK), devtool and Toaster make it easier to get the best out of Yocto.

We envisage two distinct workflows, layer maintenance and application development.

Layer Maintenance

  • Layers and recipes are edited as necessary. Poky or Toaster is used to build image that exercises layers under test

Application Development

  • Poky or Toaster is used to generate a minimal eSDK installer.
  • A developer uses resulting eSDK to create/modify an application by using devtool (iterative process).
  • Once application is complete its recipe is added to a layer and Toaster is used to build an image that includes it

There are two personas in this scenario; 'os-dev' who maintains the OS image and generates its extensible SDK and the 'app-dev' who creates new applications to run on OS. The scenario assumes that an early version of the application exists but it needs features added and to be integrated into OS image. We recognize that in smaller organizations the roles of os-dev and app-dev may be blurry but the concept of two separate personas simplifies description of workflow.

The set-up instructions at the end of this page represent the "what can currently be done" version of the workflows.

Workflow Vision

This section calls out the workflows in more detail, describing specific use of tools in each step.

Build OS Image

  1. On OS of your choice start containerized Poky or Toaster instance.
  2. If running Poky container on Windows or Mac you must also start the samba container so that host OS has access to files in the container.
  3. Add new layers and packages as required to create OS on which applications will run
  4. Build image and validate

Creating Extensible SDK

  1. Build image as above
  2. Then build Extensible SDK
  3. Publish components required for app development
    1. eSDK installer
    2. eSDK updater files
    3. shared state

Application Development

One time set-up on OS of your choice

  1. Create docker volume so that files fetched and created in the container are visible to host OS.
  2. Use extensible SDK container to install eSDK to volume.
  3. Development can also be done on the command line.
  4. Optionally install Eclipse and CROPS plug-in that

App development

  1. Start extensible SDK container so you can run devtool from command line or invoke it from Eclipse plug-in.
  2. Start samba container so that files are visible to host OS
  3. Use devtool to 'add' application project from its URL. This pulls down source code, tries to work out dependent packages and generates a recipe
  4. Although generated recipe will likely build, it may need some tweaks to some of the tasks (e.g. configure, compile, install)
  5. Once app is building, iteratvely develop using devtool (or Eclipse) to deploy and test on target
  6. Build new image including new layer and recipe and validate

Layer Maintenance

  1. os-dev: On OS of your choice install containerized 'production' toaster instance. There will a number of containers; one with toaster and core tools, the other with a toaster database. These will have to be hooked together via bind mounts. Details TBD.
  2. os-dev: Set up your base distro build with toaster by simply importing appropriate configuration (e.g. Ostro)
  3. os-dev: Add layer(s) required by packages you add to image
  4. os-dev: Update and/or add layers as required with iterative image builds
  5. os-dev: Push layer updates to appropriate repo when done
  6. os-dev: Add new layer and application package to Toaster
  7. os-dev: Build image and validate

Instructions for Workflow in Current Form

If you are inside a corporate firewall, install and configure the Chameleonsocks container based proxy solution. Then install docker.

You have choice between using the Yocto Project tools on the command line with the Poky container or by using the Toaster web interface. Toaster is easier to get going but most needs more work to get the best of out interface (see section below), so these instructions will assume use of the command line.

Toaster Setup

https://github.com/crops/toaster-container/blob/master/README.md


Build and Publish eSDK

This section is not part of the developer workflow but documents how the SDK components are generated and published. This step creates a small installer that is made available to the developer. You must have access to an http server so you can publish SDK update files.
Building and publishing the SDK takes a number of steps. Toaster will be updated to make this process much simpler.

Configure and build extensible SDK

Set the following variables. Normally this would be done in local.conf but as we are using toaster we add them as bitbake variables.

SDK_EXT_TYPE = "minimal" ensure a minimal SDK build. This produces a small installer and enable components to de downloaded as they are installed
SDK_INCLUDE_PKGDATA = "1" forces a 'world' build up to do_packagedata and is required to populate sstate-cache with all packages, as we don't know which ones developers will need. If you know the packages the application developers will require, add then the your build and avoid setting SDK_INCLUDE_PKGDATA for a much faster build.
SDK_UPDATE_URL points eSDK to URL that contains updates
SDK_EXT_TYPE = "minimal"
SDK_INCLUDE_PKGDATA = "1"
SDK_UPDATE_URL = "http://my.server.com/path/to/esdk-update"

Now set SSTATE_MIRRORS URL so devtool can use your sstate-cache to avoid re-building packages. This is normally done by setting SSTATE_MIRRORS in conf/sdk-extra.conf but this is not possible as we're using toaster. Instead ensure you are not already using an existing SSTATE_MIRROR and set bitbake variables as follows

SDK_LOCAL_CONF_WHITELIST = "SSTATE_MIRRORS"
SSTATE_MIRRORS = "file://.* http://my.server.com/path/to/sstate-cache/PATH" 

Build SDK by building your-image:populate_sdk_ext in toaster.

Publish SDK Updater

The eSDK allows web updates, so you have to ensure they appeat at the URK specified by SDK_UPDATE_URL. Assume /var/www/html/path/to is served up as http://my.server.com/path/to
In the docker shell created when you started Toaster container run the following

oe-publish-sdk tmp/deploy/sdk/distro-image-toolchain-ext-ver.sh /var/www/html/path/to/esdk-update

Publish installer

Copy installer to web server and give this URL to your app developers.

cp tmp/deploy/sdk/distro-image-toolchain-ext-ver.sh /var/www/html/path/to/sdk-installer.sh

Publish SSTATE

cp -r build/sstate-cache /var/www/html/path/to/sstate-cache

Application Development

Install and Use eSDK

  • This assumes you have docker already installed as per Toaster instructions. No other dependencies are required (that the beauty of containers).
  • Create folder for esdk bind mount where output from container will appear, say /path/to/esdk/workdir
mkdir /path/to/esdk/workdir
docker run --rm -it -v /path/to/esdk-workdir:/workdir crops/extsdk-container --url https://downloads.yoctoproject.org/tools/support/workflow/poky-glibc-x86_64-core-image-minimal-i586-toolchain-ext-2.2.sh

If you see the error ERROR: The extensible sdk cannot be installed as root. it means that the folder /path/to/esdk-workdir does not exist

Missing Features

These are the features currently missing from the above workflow vision. Think of these as stories in an Agile development environment, rather than bugs. Where possible these are linked to bugzilla entries.

  • Toaster: Base configuration (e.g. define what was Ostro in single configuration file) [9588]
  • Toaster: Simple generation of eSDK installer in Toaster. [9297]
  • Toaster: Layer Maintenance workflow. Requires "local layers" re-design. No bugzilla entry, but see design proposal video
  • Toaster: Publish layer to Layer Index from Toaster [9895]
  • CROPS: Application builder (but running eSDK in a container gets us close). [10119] [4209]
  • CROPS: Eclipse integration. In progress. No bugzilla entry.