The product recipe can reference both local application archives and remote separate repositories. Want to play with latest bleeding edge wpa_supplicant for WiFi? No problem, just link it's Git repo in your custom product recipe and it will be downloaded during build:
It will override any parent wpa_supplication version in the inheritance chain. Notice the format! It's a standard web URL with the colon character removed from "http://".
A list of all supported recipe reference formats:
The file nard/apps/openLightingArchitecture/README contains further examples.
Adding a new application requires some general knowledge about Make, shell scripts and gcc. However, have you ever written a Makefile you'll be fine. Start with creating a directory and download the package. It's advised to name the directory in same manner as the downloaded file:
Extract your downloaded tarball and inspect how to build it. Does it have a configure script? Is there a Makefile already?
We can see there is a configure (1) script bundled. The file INSTALL (2) likely holds some valuable information too.
Lets invoke the configure script to see what are our options:
There are a whole lots of options for tweaking the build. (Most of them removed here for clearity.) The important options tend to be prefix, sysconfdir, host, sysroot, CFLAGS and CPPFLAGS which we'll set in our custom cross-compile Makefile.
Let's create a Makefile by using an existing as a template:
Open the created nard/apps/mpg123/Makefile in a text editor and find the target $(PKG_VER)/.nard-build. Modify the build command to:
Next open the product recipe in a text editor:
Add a line to the PKGS_APPS list.
Note the format of the existing lines! First the application
directory name, followed by a slash and last the application
directory name again with a trailing version number. This should
resolve to your downloaded tarball. For example, by adding:
PKGS_APPS += mpg123/mpg123-1.21.0
there should be a corresponding file:
which will be automatically extracted during the build.
Now try build, push and test:
Hmm, that didn't work… Wait, what is that on the first line of
OSS is deprecated and not available in Nard. We need mpg123 to use ALSA only.
Going back to the mpg123 sources we run ./configure --help once more and search for clues… It turns out we also need the configure options --with-audio=alsa --with-default-audio=alsa in our nard/apps/mpg123/Makefile:
With the modified Makefile we try again:
Failed build. The ALSA audio library couldn't be found!
Although ALSA is available in Nard we need to enable it as well:
Now build yet again:
Success! We can now play MP3 files. You may want to inspect the files:
for the end result. Use amixer from the alsa-utils package to control volume.
An extention to Nard enables installation of binary .deb files from the Raspbian Wheezy archive. Dependencies are resolved automatically, just as with apt-get. Simply add e.g. "nano" to a configuration file and you get a fully featured text editor in the target.
Applications natively available in Nard are tuned for low resources and are thus the preferred choice. Raspbian on the other hand is heavy weight, with lots of bells and whistles and should therefore be avoided in embedded systems. Nevertheless, Raspbian has LOTS of packages readily available, so if you find integrating new applications manually are too overwhelming, this might be the remedy. Especially during development it's handy for temporary tools like packet sniffers, text editors, performance testers and such alike. Beware of "huge" applications though, they are unlikely to work. Stick with small utilities and daemons. Here is a list of applications known to operate well:
|xmas.py from Raspbian
Search for additional packages here. Configuration of what Debian/Raspbian packages to install mimics product recipes (inherits ancestor). Here is a simplified example:
As can be seen in the illustration, inherited products bring their Debian packages along, just as with native Nard applications. The file nard/platform/audit/debian.config can be used as a configuration template. Remember to enable the Debian layer itself, as well as these required build utilities in your product recipe:
Please note that the Debian compatibility layer is not as perfect as apt-get and still somewhat experimental! Occasionally it may need manual intervening. Also, daemons are installed but they aren't automatically started at boot (arrange yourself). Feedback and comments are welcome. The Debian compatibility layer is part of the add-on.
The introduction showed how new products may inherit from an elementary; and herewith features can be added on top of a solid base. Look at the mediaplayer example product which does this:
The Rules.mk (1) above contain a dependency on the skeleton example product like this:
Through this dependency everything in skeleton (such as SSH, BusyBox etc.) will emerge in mediaplayer too. By adding applications in Rules.mk (1) "on top" of skeleton we build a new product:
Here we add mpg123 for audio and fbi for pictures.
Our mediaplayer launches whenever the system boots by creating the file rc.mediaplayer (3) with content:
Finaly there is a custom kernel configuration (4). It is almost identical with the corresponding from skeleton, with the addition of sound and framebuffer drivers enabled.