CELF Technical Jamboree #15
July, 12, 2007

[original file is 09.組み込みLinux開発環境.txt]
[note taken by M. Nishikawa; translated by ikoma]

Embedded Linux Development Environment

Maehara, Yamaha

* Introduction

Overview of embedded Linux development environment
- rarely talked topics, unexpectedly
- mainly on building packages
- development cycle
case studies, discussion
- Use of APT/RPM
- Development support tools

* The distance between helloworld and prduct development

Typical development environment for embedded Linux
- Cross compilation
- Use of tftp/nfsroot
- No need to transfer firmware
  - ==> No need to reboot
Textbooks end here (Hello world)
A lot of options after that
- ==> These are seldom talked openly

* Don't you have such an experience?

High portability requirement
- co-existence of x86 and embedded processors, depending on product price zone
- Shared implementation with PC application
Binary management
- test, test.orig, test.old, test.070712, ...
  - ==> management chaos
Development by many developers
- Things get more complicated
- Embedded Linux has gotten popular; but there are few veterans
  - ==> e.g diagram of cross development environment is a jabberwock for new comers
Information specific to embedded systems
- Information on general Linux is widely available
  - ==> Info specific to embedded systems is difficult to get

* Build system

Used Autotools
- A lot of actual cases
- Implemented in perl/m4/sh
- Generates configure/Makefile
- Autotools itself is not necessary just to compile
Serveyed other tools too:
SCons
- Blender, DOOM 3 SDK, ...
- Implemented in Python
- Generates files specific to the environment
- Generate execution file specific to the environment (Windows etc.)
Cmake
- KDE4, cdrkit, Rosegarden, ...
- Implemented in C++
- Generates files specific to the environment
KBuild
- linux2.6
- Uses Makefile
Investigated build systems in Fedora7
- Checked build tools used
  - two thirds use Autotools
  - make : 18%
  - ant: 3%
  - The rest are SCons, original scripts, etc.
Conclusion
- Autotools is widely used
  - Use cases as cross development environment are limited
  - Easy to use; hard to adapt
  - Frequent update of specification causes low compatibility between versins
  - m4 is difficult
    - Using with complaints?
- No motivation to shift to alternative??

* Packaging systems

Formats
- Archive + metadata + something
  - tgz (slackware)
  - RPM (RedHat)
  - DEB (Debian)
Update tools
- Installs appropriate packages taking dependency into consideration
  - UP2DATE
  - APT
  - YUM
Comparison
- No big difference in functions
  - Packaging system is chosen depending on distribution
- User-friendliness of update tools and abundance of packages available are important
- Easy to use; hard to build

* Development cycle

In-house craft model
- One or a few developers grasp the whole system and build systems manually
- LFS (Linux From Scratch)
Source code oriented model
- Do everything at building time, using Makefiles or such kind of scripts
- Gentoo, *BSD
Binary code oriented model
- Packages all components in the system and combines them
- Fedora, Debian
  - ==> They adopted this approach
Others
- Gets source code from Debian, patches as wanted and builds up

* Development cycle of Debian

* APT for MontaVista Linux

All componets are RPM(MVL)'ized
Available both from host and target
- Package commands can be issues from host and target
Wrapper of APT
- Dir, Dir::Bin::rpm,
  - RPM::PM,
    RPM::RootDir, RPM::Options
  - ==> This wrapper enable to update the toolchain and the target file system
    - The latest development environment is always available
This can be applied to other distributions
Trend of the cross development environment
- -APT-MVL-RPM
  - MontaVista officially supports (MVL5.0)

* Merits of APT/RPM

* Issues to use APT/RPM

Handling on cross development environment is dependent on systems
- File locations
- Names of cross tools
- Automatic generation of dependency
  - To check depedency among libraries, you have to develop original script
Knowledge on packaging required
- Entry barrier is high; confortable once accustomed
Deployment onto final products
- Application to updater, etc.
  - ==> Introduce per-package update system onto final products
- Database size is large
  - ==> Serious problem for memory/storage tight systems
- Problems when database broken

* NGSProject

Implemented for smooth management of development cycle
- Generates necessary files based on templates
- Supports building, packaging through release
Demonstration
- ==>Describes interactively package name, project summary, version, README
  - as well as license, source code archiving method etc. Supports through package generation

* Issues of NGSProject

User friendliness
- User interface based on dialog (ncurses)
- Sophisticated inquiry
  - == Difficult without underlying knowledge
Direction
- Would like to establish development cycle to concentrate on devlopment of product intrinsic part
- Eclips may be an answer
- Appropriate for open source development?
  - ==> How about sharing, as irrelevant to unique part of products?

* Conclusion

What is necessary after helloworld
- Scalable develpment environment
  - APT/RPM
- Smooth management of develpment cycle
  - NGSProject
How about your project?
- Building and packaging of product intrinsic part
  - Issues on that
- Knowhow of buiding/packaging
  - Documentation? Making tools?

* On other projcts?