Target Wizard

From eLinux.org
Revision as of 19:17, 20 November 2012 by Tim Bird (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Target Wizard was the user interface and build tool for Lineo's Embedix distribution of embedded Linux.

See this article for a good overview of the product: http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/A-developers-review-of-Lineos-Embedix-SDK/

Main Features

Here are the main features of Target Wizard

  • Graphical tool to select configuration of embedix
    • a configuration language (ECD) was used to create a unified configuration space for all packages
      • This pre-dated the modern Kconfig era, and was developed about the same time as CML2 by Eric Raymond
      • A tool, config2ecd was used to convert the kernel's config.in syntax to ECD syntax
  • The graphical tool handled dependencies between packages and between packages and the kernel, and the deployment system
  • shell-fragment based build system - based on RPM
  • output of the build system was binary and source RPMS
  • Could create a single shell script which performed all the build steps from a single file
  • license evaluation tool
  • keep-list concept - ability to control at file granularity the items to be put on target
  • merge directory - ability to easily add 3rd-party items to the build on target
  • deployment wizard - set of python scripts that walked you through creating final images and actually deploying them on the target
    • Lineo's custom-built wizard system allowed for backtracking through the wizard
  • Target Wizard used python as an extension language, for scripting some tasks
  • lipo - library reduction tool
  • documentation collection tool - generated documentation for all the different packages, and built

a single HTML tree from all the different documenation sources.

    • There were scripts describing the type of doc content for each package, how to convert it to html, and where to place it in the global documentation scheme.

Some remembrances

Dealing with how to disable/enable sub-trees (conditionally) in the GUI was a major issue. The gui had the capability to show what other option needed to be enabled, in order to enable a particular option. For each package, the tool could show what the keep list was, and what the resulting size of the image would be, for the options and keep list selected.