Overview

Definition files are used as input to the Build Tools mksys, mkapp, mkexe, and mkcomp (known collectively as the mk tools).

All def files use a Common File Format.

.adef Files

These definition files, together with Language-Independent APIs, make it easier to develop component-based software and allows a great deal of boiler-plate code to be automatically generated.

Interfaces are defined using .api files. Implementations of those interfaces are constructed as reusable components. Components can be combined into applications. Apps can be installed and run on target devices. Apps can also be integrated into systems of inter-communicating applications deployed together to target devices in a single step.

.cdef Files

Component definition .cdef files are used to define the external interfaces and internal content of reusable software components.

Each component has a single Component.cdef file, which defines:

• source code files are used to build the component
• files from the build system are to be included in any app that includes the component
• files on the target are to be made accessible to any app that includes the component
• IPC interfaces the component implements
• other components are needed by this component
• memory pool sizes (future)
• configuration settings for the component (future)

Application definition .adef files are used to define the external interfaces and internal content of applications that can be built, installed, and run on target devices.

.adef files can also be used to override some settings of components without having to change those components themselves, thereby making the components more reusable.

Each application has a .adef file, which defines:

• executables should be built from what components
• additional files from the build system are to be included in the app
• processes should be started (by running what executables with what command-line arguments and environment variables) when the app starts
• if the app should automatically start when the target device boots
• files (or other file system objects) from the target root file system are to be made available to the app at runtime
• limits should be placed on the app at runtime (such as cpu limits, memory limits, etc.)
• overrides for memory pool sizes and configuration settings for components in the app (future)
• IPC bindings between components within the app
• IPC interfaces will be made visible to other apps

.sdef Files

System definition .sdef files are used to interconnect applications with each other and with the target's runtime environment (e.g., hardware devices).

.sdef files can also override some app settings eliminating actually changing the apps.

A .sdef file defines a system of one or more applications that can be deployed to target devices in the field. Each .sdef file lists:

• apps are to be installed on the device
• IPC connections are permitted between apps
• overrides for limits, configuration settings, and IPC bindings within apps

Numbers

Integers are required in some sections.

maxFileDescriptors: 100

Numbers can be expressed in Kilobytes (bytes x 1024) by adding the 'K' suffix.

maxFileSystemBytes: 120K

Build Tool Search Paths

Two are used:

• source search path - lists file system directories where the build tools look for source code files and components.
• interface search path - lists file system directories where the build tools look for interface definition files (.h files and .api files).

The default search path “.” is the current working directory where the build tool ran.

Search paths can be changed through mk tools command-line options:

• '-s' sets the source search path
• ‘-i’ sets the interface search path

$ mksys packageTracker.sdef -i ~/work/interfaces -s ~/work/components

Precedence and Overriding

Settings in a .sdef file override settings from both the .adef and Component.cdef, while the .adef overrides settings in the Component.cdef. This increases reusability by allowing an integrator to override a component's or app's settings without having to change that component or app.

Also, most configuration settings can be overridden on the target device at runtime (although, some will not take effect until the application is restarted).

Environment Variables

It is possible to use environment variables inside of .sdef, .adef, and Component.cdef files.

This is done in the same way as in shell scripts, by prefixing the environment variable name with a dollar sign ($).

requires:
{
    api:
    {
        $BUILD_ROOT/interfaces/httpdCtrl.api
    }
}

If necessary, the variable name can also be enclosed in curly braces.

requires:
{
    api:
    {
        ${PRODUCT_FAMILY}_interfaces/httpdCtrl.api
    }
}

Some useful environment variables:

• LEGATO_ROOT = path to where the Legato framework sources are located
• TARGET = build target (e.g., ar7, wp7, localhost)
• LEGATO_BUILD = shorthand for $LEGATO_ROOT/build/$TARGET

---

Copyright (C) Sierra Wireless, Inc. 2014. Use of this work is subject to license.