Developer Workflow Improvements: Difference between revisions

From Yocto Project
Jump to navigationJump to search
No edit summary
m (→‎Configure: small typo)
 
(80 intermediate revisions by 3 users not shown)
Line 1: Line 1:
Developer workflow improvements as documented in the following bugzilla entry:
Back to Yocto Project [[Main Page]]
= Introduction =
The page describes how new tools such as [https://www.gitbook.com/book/dnplas/yocto-project-crops/details Cross Platform Support] (CROPS), [http://www.yoctoproject.org/docs/current/sdk-manual/sdk-manual.html#sdk-extensible-sdk-intro Extensible SDK] (eSDK), [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#dev-modifying-source-code devtool] and [https://www.yoctoproject.org/docs/current/toaster-manual/toaster-manual.html#toaster-manual-intro Toaster] make it easier to get the best out of Yocto. To benefit from this article the reader must be comfortable with the basics of the Yocto Project (i.e. has gone through [http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html Quick Start Guide] and knows how to add packages to an image).


https://bugzilla.yoctoproject.org/show_bug.cgi?id=6662
We envisage two distinct workflows, layer maintenance and application development.


== Todo list ==
== Layer Maintenance ==
* This workflow is mainly bug fixing recipes and upgrading to never versions. Updated recipes are then submitted to layer maintainers. It also includes building images that exercise the recipes under test.
* Typically this is done in the distro maintainer (i.e. bitbake) environment, but the extensible SDK can be a better option as it enables an easy to configure common development environment.


=== SDK ===
== Application Development ==
* Properly report failures in bitbake execution during install (output is currently discarded)
* Poky or Toaster is used to generate a minimal eSDK installer.  
* Prevent do_rootfs itself from executing on install - we only need the tasks that it depends upon
* A developer uses resulting eSDK to create/modify an application by using devtool (iterative process).  
* Write test script for SDK
* Once application is complete its recipe is added to a layer and Toaster is used to build an image that includes it
* Randy: getting errors from bitbake about changed signatures - behaviour change after Hongxu's patch?
* Update environment setup script to use buildsystem toolchain -- ''Done but needs testing and function dependent on uninative - Randy''
* Fix runqemu''(and possibly other tools?)'' since we no longer have the nativesdk sysroot ''(Add them to buildtools-lite?)''
* Refactor to move functionality to SDK classes rather than meta-newsdk recipe
* nativesdk-qemu-helper_1.0.bb and qemu-helper_1.0.bb don't publish the same set of files. Investigate, since runqemu(and possibly other things) may need to come from the buildsystem's native sysroot.
* Installing the sdk to /opt requires root perms, but if you run the installer under sudo/as root then the inner execution of bitbake to prepare the SDK fails at sanity check
* uninative-tarball errors when restoring from sstate (should it even try?)
* uninative-tarball reports "WARNING: Function  doesn't exist" during build
* Error when running recipetool from devtool "Error: The OE SDK/ADT was detected as already being present in this shell environment. Please use a clean shell when sourcing this environment script." - probably need to bypass this check via an extra environment variable
* When publishing the SDK(tool not available yet), warn the user if there are items added to the image/distro via local.conf and suggest moving the items the distro or image config.


=== devtool ===
= Workflow Vision =
* <strike>Need to run do_populate_sysroot when you run "devtool build" (so that libraries can be added)</strike>
This section calls out the workflows in more detail, describing specific use of tools in each step.
* <strike>Add an option for modify / add to use the same directory for source and build where that's required</strike>
* Add support for plugins in multiple layers
* Support 'devtool modify linux-yocto' - externalsrc doesn't seem to work here at the moment -- ''Started, paused until Bruce's patchset is ready - Paul''
* Use git to track changes made by extra task functions?
* extract: Try to get author/date info about patches from metadata git history if not able to find it any other way?
* update-recipe: warning when running on mdadm: WARNING: Variable key FILES_${PN} ( ${base_libdir}/udev/rules.d/*.rules) replaces original key FILES_mdadm


=== recipetool ===
The [[Developer Workflow Improvements#Instructions for Workflow in Current Form | set-up instructions]] at the end of this page represent the "what can currently be done" version of the workflows.
* Rudimentary spec file conversion?
 
* Ability to do interactive adds via a UI
== Build OS Image ==
* Add comments in on do_configure(_append), do_install_(append) etc.
# On OS of your choice start containerized Poky or Toaster instance.
* Handle USE_* options in Makefiles?
# 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.
* Extract dependencies from cmake
# Add new layers and packages as required to create OS on which applications will run
* LICENSE files can be picked up twice if they match more than one expression in our list e.g. COPYING.GPL
# Build image and validate
 
== Creating Extensible SDK ==
# Build image as above
# Then build Extensible SDK
# Publish components required for app development
## eSDK installer
## eSDK updater files
## shared state
 
== Application Development ==
=== One time set-up on OS of your choice ===
# Create docker volume so that files fetched and created in the container are visible to host OS.
# Use extensible SDK container to install eSDK to volume.
# Development can also be done on the command line.
# Optionally install Eclipse and CROPS plug-in that
=== App development ===
# Start extensible SDK container so you can run devtool from command line or invoke it from Eclipse plug-in.
# Start samba container so that files are visible to host OS
# Use '''devtool''' to 'add' application project from its URL. This pulls down source code, tries to work out dependent packages and generates a recipe
# 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
# Build new image including new layer and recipe and validate
 
== Layer Maintenance ==
# Build image as above
# Use '''devtool modify''' to update recipe
# Iterative development as per application development.
# Build image and validate
# Publish updated recipe
 
= Instructions for Workflow in Current Form =
If you are inside a corporate firewall, install and configure the [https://github.com/crops/chameleonsocks Chameleonsocks] container based proxy solution.
 
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.
 
== Build OS image ==
We recommend that you first [https://github.com/crops/docker-win-mac-docs/wiki install docker] on your OS of choice and then follow instructions to set up [https://github.com/crops/poky-container/blob/master/README.md Poky] or [https://github.com/crops/toaster-container/blob/master/README.md Toaster] containers. However, these instructions will work for Poky or Toaster on Linux directly but you're on your own for installation and configuration.
 
Now add layers and configure so you can build your image.
 
== 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. <br/>
Building and publishing the SDK takes a number of steps.
=== Configure ===
Set the following variables in local.conf
:<tt>SDK_EXT_TYPE = "minimal"</tt> ensure a minimal SDK build. This produces a small installer and enable components to de downloaded as they are installed
: SDK_UPDATE_URL points eSDK to URL that contains updates
:Optionally set <tt>SDK_INCLUDE_PKGDATA = "1"</tt> to help eSDK users by pre-building all packages in all layers (i.e. not just packages included in the image). The installer remains small as build data is made available via sstate mirror. Downside is that eSDK build will take much longer.
 
Here are some example settings
SDK_EXT_TYPE = "minimal"
SDK_UPDATE_URL = "http://my.server.com/path/to/esdk-update"
SDK_INCLUDE_PKGDATA = "1"
 
The URL for the eSDK sstate mirror is not included in the above settings as it would conflict with the mirror used by the main build system. To handle this conflict, the value in put into a separate conf file <tt>conf/sdk-extra.conf</tt>
SSTATE_MIRRORS = "file://.* http://my.server.com/path/to/sstate-cache/PATH"
Note that if you are using Toaster, you don't have access to <tt>conf/sdk-extra.conf</tt>, so you have to set variables via the U/I. This means that Toaster cannot have an sstate mirror for the OS build and set the eSDK's as follows:
SDK_LOCAL_CONF_WHITELIST = "SSTATE_MIRRORS"
SSTATE_MIRRORS = "file://.* http://my.server.com/path/to/sstate-cache/PATH"
 
=== Build ===
Assuming image name is my-image, build as follows from command line
bitbake my-image -c populate_sdk_ext
If using Toaster, build <tt>my-image:populate_sdk_ext</tt>.
 
=== Publish SDK Updater ===
The eSDK allows web updates, so you have to ensure they appeat at the URK specified by SDK_UPDATE_URL. Assuming /var/www/html/path/to is served up as http://my.server.com/path/to, publish as follows
oe-publish-sdk tmp/deploy/sdk/distro-image-toolchain-ext-ver.sh /var/www/html/path/to/esdk-update
 
=== Publish SSTATE ===
cp -r build/sstate-cache /var/www/html/path/to/sstate-cache
 
=== 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
 
== 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
* Run container, pointing to URL of eSDK minimal installer. You must do this every time you want to use eSDK. In this example I'm suing an eSDk installer I created that is available at  https://downloads.yoctoproject.org/tools/support/workflow/poky-glibc-x86_64-core-image-minimal-i586-toolchain-ext-2.2.sh
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
* You now be in the eSDK container shell.
** For more details on eSDK container see https://github.com/crops/extsdk-container.
* Now follow instructions from [https://wiki.yoctoproject.org/wiki/Cookbook:Example:Creating_and_updating_recipes_with_devtool Yocto Project cookbook] on building an app.
* Recipe will be available in /path/to/esdk/workdir/workspace/recipes/bbexample/
 
= 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) [https://bugzilla.yoctoproject.org/show_bug.cgi?id=9588 [9588]]
* Toaster: Simple generation of eSDK installer in Toaster. [https://bugzilla.yoctoproject.org/show_bug.cgi?id=9297 [9297]]
* Toaster: Layer Maintenance workflow. Requires "local layers" re-design. No bugzilla entry, but see [https://www.youtube.com/watch?v=z5wVjBwJDzY design proposal video]
* Toaster: Publish layer to Layer Index from Toaster [https://bugzilla.yoctoproject.org/show_bug.cgi?id=9895 [9895]]
* CROPS: Application builder (but running eSDK in a container gets us close). [https://bugzilla.yoctoproject.org/show_bug.cgi?id=10119 [10119]] [https://bugzilla.yoctoproject.org/show_bug.cgi?id=4209 [4209]]
* CROPS: Eclipse integration. ''In progress. No bugzilla entry.''

Latest revision as of 19:52, 24 January 2023

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. To benefit from this article the reader must be comfortable with the basics of the Yocto Project (i.e. has gone through Quick Start Guide and knows how to add packages to an image).

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

Layer Maintenance

  • This workflow is mainly bug fixing recipes and upgrading to never versions. Updated recipes are then submitted to layer maintainers. It also includes building images that exercise the recipes under test.
  • Typically this is done in the distro maintainer (i.e. bitbake) environment, but the extensible SDK can be a better option as it enables an easy to configure common development environment.

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

Workflow Vision

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

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

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. Build image as above
  2. Use devtool modify to update recipe
  3. Iterative development as per application development.
  4. Build image and validate
  5. Publish updated recipe

Instructions for Workflow in Current Form

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

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.

Build OS image

We recommend that you first install docker on your OS of choice and then follow instructions to set up Poky or Toaster containers. However, these instructions will work for Poky or Toaster on Linux directly but you're on your own for installation and configuration.

Now add layers and configure so you can build your image.

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.

Configure

Set the following variables in local.conf

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_UPDATE_URL points eSDK to URL that contains updates
Optionally set SDK_INCLUDE_PKGDATA = "1" to help eSDK users by pre-building all packages in all layers (i.e. not just packages included in the image). The installer remains small as build data is made available via sstate mirror. Downside is that eSDK build will take much longer.

Here are some example settings

SDK_EXT_TYPE = "minimal"
SDK_UPDATE_URL = "http://my.server.com/path/to/esdk-update"
SDK_INCLUDE_PKGDATA = "1"

The URL for the eSDK sstate mirror is not included in the above settings as it would conflict with the mirror used by the main build system. To handle this conflict, the value in put into a separate conf file conf/sdk-extra.conf

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

Note that if you are using Toaster, you don't have access to conf/sdk-extra.conf, so you have to set variables via the U/I. This means that Toaster cannot have an sstate mirror for the OS build and set the eSDK's as follows:

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

Build

Assuming image name is my-image, build as follows from command line

bitbake my-image -c populate_sdk_ext

If using Toaster, build my-image:populate_sdk_ext.

Publish SDK Updater

The eSDK allows web updates, so you have to ensure they appeat at the URK specified by SDK_UPDATE_URL. Assuming /var/www/html/path/to is served up as http://my.server.com/path/to, publish as follows

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

Publish SSTATE

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

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

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.