The Mer Wiki now uses your Mer user account and password (create account on https://bugs.merproject.org/)

Platform SDK

From Mer Wiki
Revision as of 10:59, 9 March 2012 by Timoph (Talk | contribs)

Jump to: navigation, search

Contents

Mer platform SDK

To avoid any confusion, there are two types of SDKs: Application SDKs and Platform SDKs. Application SDK's are the ones that deal with Qt applications and libraries, HTML5, etc, while Platform SDK's are for developing the platform, compiling native code and other things revolving around the platform developer/hacker needs.

The platform SDK aims to offer a installable disk image that can be run on virtual machines (typically) or actual hardware, which contains tools like Scratchbox2, MIC (image creator), spectacle, osc, qemu, etc preinstalled, to make it easier for a developer to work with Mer.

Please note that the platform SDK is a work on progress. The work for making the sdk was kicked off January 13 2012. If you are willing to contribute to the effort, please do so.

Using the platform SDK

Please note that this is a DRAFT and not all bits and pieces are in place yet. Also things might and most likely will change.

SDK Requirements

The chroot SDK will run on most modern linux machines. It needs:

  • about 400Mb free space to install
  • hundreds of Mb for rpm caches for osc and mic
  • Generic x86 CPU
  • user must have sudo rights

WARNING

The SDK consists of a directory tree and when you 'mount' the SDK you will link your home directory, root directory and any data directories within this tree.

Because of this you *MUST* 'umount' the SDK before deleting it - if you don't then you *WILL* lose data.

If you are unfamiliar with bind mounts, the safest way to uninstall is to reboot your machine and remove the SDK *BEFORE* using the sdk 'mount' command.

Please do not be alarmed by this - we're simply letting you know that running an "rm -rf" command in the wrong place is dangerous. It's better to explain this in big letters than risk someone losing data by mistake :)

Obviously people working on SDK development and testing should take particular care.

Installation / setup

The platform SDK is provided as a rootfs tarball that contains essential tools for Mer platform development along with a helper script to enter the rootfs.

Please note that the platform SDK requires that you're using a Linux distribution (one in a virtual machine works well).

The SDK can be installed to any location with enough space - we'll use /srv/ as per the Linux FHS (feel free to adapt the commands to use any other location).

The installation path must contain an intermediate directory called 'sdks' which only has Mer SDKs inside. eg /srv/mer/sdks/sdk/...

To setup the SDK:

Check: https://img.merproject.org/images/sdk/latest/images/mer-sdk-i486-chroot/ for the name of the latest tarball

  • Download the latest stable SDK rootfs tarball. 
cd $HOME
curl -k -O https://img.merproject.org/images/sdk/latest/images/mer-sdk-i486-chroot/<LATEST>
  • Create directory for the SDK rootfs and extract the tarball as root or with sudo 
sudo mkdir -p /srv/mer/sdks/sdk
cd /srv/mer/sdks/sdk
sudo tar --numeric-owner -p -xjf $HOME/mer-sdk-i486-chroot-<LATEST>.tar.bz2

SDK control script

The platform SDK rootfs contains a helper script to enter the chroot named 'mer-sdk-chroot'. The helper script is located the the root directory (/) of the rootfs. It requires you to have sudo ability.

As mentioned, the SDK is location independent so it uses the location of the helper script to determine which SDK to enter.

Connect the SDK using 'mount'

You need to connect the SDK before using it. This only needs to be done once (well, once each time you boot your machine) and it connects things like /proc and $HOME in the SDK. It also links /parentroot of the SDK to your normal / directory.

Under normal use the SDK does not need to be disconnected. As per the warning above, you should disconnect using 'umount' before removing the SDK (see remove/disconnect info below)

To connect run: 

  /srv/mer/sdks/sdk/mer-sdk-chroot mount

You can now use the SDK from multiple terminals at once.

Entering chroot

Before entering the SDK you may want to make an SDK equivalent of ".profile" to give you a nice prompt to remind you that you are in the SDK: 

 echo 'PS1="MerSDK $PS1"' >> ~/.mersdk.profile

To enter the rootfs with the helper script run 

  /srv/mer/sdks/sdk/mer-sdk-chroot enter

You should find that you are operating under your normal username and that your home directory is available as /home/<username> and any other mountpoints are mounted under /parentroot/*

You have sudo rights automatically.


Basic tasks

Building an image

Mer images are build using mic image creator. Mic takes a kickstart file that defines the image to be created as input. To create a Mer image with the platform SDK simply call mic as you would do on any other system. For example

As a test this should make a new local SDK rootfs image:

(Check: https://img.merproject.org/images/sdk/latest/images/mer-sdk-i486-chroot/ for the name of the latest KickStart file) 

curl -k -O https://img.merproject.org/images/sdk/latest/images/mer-sdk-i486-chroot/<LATEST>
sudo mic create fs mer-sdk-x86-chroot-latest.ks -o . --pkgmgr=yum --arch i486 --compress-disk-image=tar.bz2

Running osc

Since your home directory has been linked into the SDK then osc commands should work as normal. 

osc ls

Compiling with the SDK (FIXME)

Cross compilation tools are not currently available in the SDK out of the box. To setup cross compiling for N950 (armv7hl) do the following inside the sdk chroot 

sudo zypper ref
sudo zypper in scratchbox2 qemu-usermode

add repository containing cross compiler and install needed packages from there 

sudo zypper ar http://releases.merproject.org/releases/0.20120209.1/builds/armv7hl/packages/ cross
sudo zypper ref
sudo zypper in cross-armv7hl-gcc cross-armv7hl-binutils

extract Nemo N950 rootfs to for example your home directory 

mkdir -p $HOME/n950rootfs
cd $HOME/n950rootfs
sudo tar xjvf /path/to/nemo-n950-image.tar.bz2

Set file permissions for the n950 rootfs 

sudo chown -R <your username> n950rootfs

you might also need to give write permissions to some places like bin, sbin and so on. 

sudo chmod u+w bin

initialize scratchbox2 

cd $HOME/n950rootfs
sb2-init -d -L --sysroot=/ -C --sysroot=/ -c /usr/bin/qemu-arm-dynamic nemo-n950 /opt/cross/bin/armv7hl-meego-linux-gnueabi-gcc

if you get an error compaining about tmp do 

sudo chmod 777 /tmp

and try again. the compiler should now work but you are still missing libraries to compile against. Install what you need into the n950 rootfs by 

sb2 -eR zypper ref
sb2 -eR zypper install ...

If the installation fails due to permission errors give your user write permissions to the places the packages are being installed and retry. After this you can compile for example a c hello world by 

cat << "EOF" > hello.c
#include <stdio.h>
int main(int argc, char **argv)
{
   printf("Hello\n");
   return 0;
}
EOF

sb2 gcc hello.c -o hello

verify that the compilation worked 

$ file hello
hello: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.25, not stripped
$ sb2 ./hello 
Hello

Packaging

The SDK includes tools needed to create rpm packages for Mer.

See https://build.pub.meego.com/package/show?package=sdk-kickstarter-configs&project=Mer%3ATools%3ATesting

Hosting repositories

To make installing created packages easier you can host your own rpm repository with the SDK and install packages to your target device from there.

TODO

SDK contents

The platform SDK's rootfs has some useful packages preinstalled that are listed below. If you're missing something you can use zypper to install the needed extra packages or if not available in the repositories compile them yourself.

  • osc and build
  • mic

Upgrading the SDK

Within the SDK you can update and upgrade your tools using: 

 sudo zypper ref
 sudo zypper up

New tools can be installed using 

 sudo zypper in <package>

Advanced details

The usage for the helper script is: 

   usage: mer-sdk-chroot [<enter>] [-u <user>] [-r <SDK root path>]
          mer-sdk-chroot mount [-u <user>] [-m <all|none|root|home>] [-r <SDK root path>]
          mer-sdk-chroot umount [-r <SDK root path>]

      This is the Mer chroot SDK.
      For information see http://wiki.merproject.org/wiki/Platform_SDK

      The SDK has 3 commands:
         enter (default)
         mount
         umount

     enter
        Used to enter the SDK and begin working. The SDK bash shell is a
        login shell. See below for .profile handling
        Must be preceded by a 'mount' to setup the SDK.
        May be used in multiple terminals and simply enters the
        chroot

     mount
        Used to setup the SDK mountpoints. Only needed once per login
        session

     umount
        Used to clean up the SDK mountpoints before removing the SDK.

     Options:

      -u  System user to link into SDK (not needed if using sudo)
      -m  Devices to bind mount from host: none, all (default)
          root, home
      -r The root of the SDK to use - normally derived from the
         pathname of mer-sdk-chroot

     Profile

     Entering the SDK runs the user's normal .profile and any (SDK)
     system profile entries. It will not execute the host's system
     profile entries.

     The environment variable MERSDK is set to 1 to allow .profile to
     detect the SDK.

     If the user has a ~/.mersdk.profile then it is sourced after the
     normal .profile handling (this allows the common use case of
     setting a profile to be handled).

     Hooks

     If the user specified has a .mersdkrc in their $HOME, it will be
     sourced to allow hook functions to be defined. Hooks are run as
     root. No commands should be executed immediately.

     These hooks are usually used to define symbolic links from any
     /parentroot/data type filesystems into the SDK root to setup
     system specific shared caches or filesystem layouts etc


Sharing mic and osc caches

You can use the ~/.mersdkrc file to check and link the standard mic and osc cache directories to those in parentroot.

Note that multiple *concurrent* instances of mic should not share the same cache (it's OK to share from different SDKs and different terminals provided they're not running and accessing the cache at the same time).

Here's some code you can use in ~/.mersdkrc to share a mic cache: 

   if [[ ! -e ${sdkroot}/var/tmp/mic ]]; then

mkdir -p ${sdkroot}/var/tmp/mic 

   fi
   if [[ ! -e ${sdkroot}/var/tmp/mic/cache && ! -h ${sdkroot}/var/tmp/mic/cache  ]]; then

ln -s /parentroot/var/tmp/mic/cache ${sdkroot}/var/tmp/mic/cache 

   fi

In your ~/.oscrc file there is a line: 

 packagecachedir = <something>/build-pkg-cache

If this is under $HOME then it will be shared anyway; otherwise do something similar to the mic cache code above.

Multiple SDKs

You should be able to install and connect to multiple SDKs at the same time.

Removing and disconnecting the SDK

Under normal use the SDK does not need to be disconnected; it's only usually needed when you want to remove an instance of the SDK.

To disconnect run: 

  /srv/mer/sdks/sdk/mer-sdk-chroot umount

Be sure that the bind-mounts(especialy the home directory) are all umounted after you disconnect the SDK. You can use 'cat /proc/self/mountstats' to check it. If it is not umounted cleanly, you should umount it manually after you exit the chroot environment.

The SDK does warn you if umounts fail. It also uses 'lazy' umounts which means that the mountpoints will go away as soon as the kernel can clean them (typically when processes exit or terminals cd out of the mounted directories.)

Once the SDK has been cleanly unmounted, it may be removed manually.

Development Documentation

Below you will find information about the development of the platform SDK itself.

Requirements

The following requirements were agreed on the initial platform sdk brainstorming meeting (things may change)

  • Platform SDK needs to be able to function without an OBS account or access to an OBS.
  • Offline compilation must be possible
  • Clearly document the difference between platform SDK and application SDK.
  • Document the SDK tools for easier porting to new Linux distributions (if all SDK tools, and nothing else, comes from a single OBS project, that might be enough documentation).
  • seperation of user /home and 'sdk'
  • need short path from: code, build, deploy, boo
  • minimal http server to SDK for built rpm repo serving

Sources and packages

QA

TBD

SDK team meeting minutes

Usefull links and further reading

Retrieved from "https://wiki.merproject.org/wiki/index.php?title=Platform_SDK&oldid=1131"
Personal tools