Difference between revisions of "ToolingUseCases"

From Openembedded.org
Jump to: navigation, search
(Target System User)
(Undo revision 3281 by Yjytalamago (Talk))
 
(8 intermediate revisions by 3 users not shown)
Line 18: Line 18:
 
* Debug Application on Target
 
* Debug Application on Target
 
* Generate build system artifacts for Application (recipes)
 
* Generate build system artifacts for Application (recipes)
 +
 +
=== Ideas ===
 +
 +
* Develop an Eclipse plugin to "Export project as Recipe"
 +
** For CDT (C/C++) projects make, automake recipes are generated
 +
** For Java projects java-library based recipies are generated
 +
** Python?
 +
** Initially wizard can just create a tarball of project sources
 +
** Integration with SCM plugins?
 +
** How to capture project dependencies?
 +
** How to define export target?  OTE, cloud, etc.?
  
 
== Distro Developer ==
 
== Distro Developer ==
  
Distro developer's concern is to compose packages and configurations into a working system.  The disto developer has deep knowledge of packages available in Linux, and how sets of packages work well together.  Additionally the distro developer is not afraid to work deeply within the build system to make it better, and to produce better, more maintainable package metadata and target systems.
+
Distro developer's concern is to compose packages and configurations into a working system.  The distro developer has deep knowledge of packages available in Linux, and how sets of packages work well together.  Additionally the distro developer is not afraid to work deeply within the build system to make it better, and to produce better, more maintainable package metadata and target systems.
  
 
=== Primary Tooling Requirements ===
 
=== Primary Tooling Requirements ===
Line 40: Line 51:
 
* Debug build issues
 
* Debug build issues
 
* Visualize Package Dependencies
 
* Visualize Package Dependencies
 +
 +
=== Notes ===
 +
 +
* OpenEmbedded Tools for Eclipse (OTE) was designed for this role type.
  
 
== Target System User ==
 
== Target System User ==
Line 45: Line 60:
 
This role type typically is not exposed to package metadata, cross compilers, or build systems.  They are system users, and as such, at times want to:
 
This role type typically is not exposed to package metadata, cross compilers, or build systems.  They are system users, and as such, at times want to:
  
 +
* Generate system
 
* Update system
 
* Update system
 
* Install packages
 
* Install packages
Line 55: Line 71:
 
* resolve package dependencies
 
* resolve package dependencies
  
[[Category:DevTalk]]
+
=== Ideas ===
 +
 
 +
* A GUI application that runs with a local install of OE that can
 +
** present a wizard style interface that allows users to build system images
 +
** download overlays and other non-default artifacts
 +
** select images, packages, distros, machines, etc.
 +
** have a simple 'installer' that does not require knowledge of bitbake/OE internals
 +
 
 +
[[Category:OEDEM]]

Latest revision as of 07:52, 24 November 2010

Overview

This page defines primary user-roles in using OpenEmbedded. The material resulted from some discussions at OEDEM that were truncated due to time restrictions.

Goals

The goal of identifying user-roles is to be able to categorize different tooling scenarios, and what types of users will be interested in specific features. Tools designed for role type may not be appropriate for other roles. For example, a GUI for recipe editing may not be helpful for an application developer that's looking to remote debug their application on a target. On the other hand, a simple press-button build GUI may not be interesting for a seasoned OE hacker.

Role Types

Application Developer

The application developer's main concern is developing and testing any given application on a target system. This person does not care nor want to learn much about the internal details of the build system or package metadata. The best possible case is that these systems are transparent and the developer is able to easily build and deploy applications to the target device.

Primary Tooling Requirements

  • Build Application for Target
  • Debug Application on Target
  • Generate build system artifacts for Application (recipes)

Ideas

  • Develop an Eclipse plugin to "Export project as Recipe"
    • For CDT (C/C++) projects make, automake recipes are generated
    • For Java projects java-library based recipies are generated
    • Python?
    • Initially wizard can just create a tarball of project sources
    • Integration with SCM plugins?
    • How to capture project dependencies?
    • How to define export target? OTE, cloud, etc.?

Distro Developer

Distro developer's concern is to compose packages and configurations into a working system. The distro developer has deep knowledge of packages available in Linux, and how sets of packages work well together. Additionally the distro developer is not afraid to work deeply within the build system to make it better, and to produce better, more maintainable package metadata and target systems.

Primary Tooling Requirements

  • Build system image
  • Create/edit distro definitions
  • Debug build problems
  • Visualize package dependencies

Package Developer

The package developer is often a mix of the previous two role types. Often they have some knowledge of the build system and applications and build tools used to create those applications. They typically act as a bridge between pure application developers and the resulting target system that's produced. Package developers write recipes, debug applications, and debug build problems.

Primary Tooling Requirements

  • Create and edit package metadata
  • Easily integrate package metadata into build system
  • Debug build issues
  • Visualize Package Dependencies

Notes

  • OpenEmbedded Tools for Eclipse (OTE) was designed for this role type.

Target System User

This role type typically is not exposed to package metadata, cross compilers, or build systems. They are system users, and as such, at times want to:

  • Generate system
  • Update system
  • Install packages
  • Configure package metadata

Primary Tooling Requirements

  • install binary package on target
  • find new packages and package updates for target
  • resolve package dependencies

Ideas

  • A GUI application that runs with a local install of OE that can
    • present a wizard style interface that allows users to build system images
    • download overlays and other non-default artifacts
    • select images, packages, distros, machines, etc.
    • have a simple 'installer' that does not require knowledge of bitbake/OE internals