All of the definition files have the same format. They're divided into sections. Each section type has a set of permitted content, which could be simple, numerical or text values, named items, or other sections (subsections).

Sections

A section always starts with a section name followed by a colon (':').

faultAction: restart
 
maxFileSystemBytes: 200K

Sections that can have multiple content items always have curly braces around their content.

sources:
{
    helloWorld.c
    myClass.cpp
}

All sections are optional; they can be empty or omitted.

Sections can be in any order, multiple occurrences are permitted, and some sections have sub-sections.

requires:
{
    file:
    {
        /dev/ttyS0  /dev/uart
    }
 
    file:
    {
        /tmp/foo  /tmp/
    }
 
    dir:
    {
    }
}

Named Items

A named item always begins with the item name followed by an equals sign ('=').

myPool = 45

If a named item can have multiple content items, then it must have curly braces around its content.

myExe = { myComponent otherComponent }

Numerical Values

Integers are required in some sections.

maxFileDescriptors: 100

Numbers can be expressed in multiples of 1024 by adding the 'K' suffix.

maxFileSystemBytes: 120K

Text Values

Some sections contain text-based values. The format of these varies depending on the type of section.

Environment Variables

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

This works 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
• LEGATO_TARGET = build target (e.g., wp85, localhost)
• LEGATO_BUILD = shorthand for $LEGATO_ROOT/build/$TARGET
• LEGATO_SYSROOT = path of the directory containing the target device's system files
• CURDIR = path of the directory containing the definition file being parsed

Whitespace

Tabs, spaces, new-lines, carriage-returns and comments act as token separators only, and are otherwise all ignored. Consequently, choice of indentation and spacing style is relatively unrestricted.

Comments

Comments can be included using

// C++-style one-line comments.
 
/* or
   C-style multi-line comments. */

Sample

/* Component.cdef file for a hypothetical web server component that provides a control API
 * (defined in httpdCtrl.api) that allows other apps to start and stop the web server via IPC.
 */
 
bundles:
{
    // Include all the web pages from the build host in the application, and have them appear
    // to the application under /var/www.
    dir:
    {
        htdocs   /var/www
    }
}
 
provides :     // Note that space is allowed between the section name and the colon.
{
    api:    {   httpdCtrl.api
            }
}
 
sources: {httpd.c}

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