The eCos Component Writer's Guide
Prev |  | Next

# parent

## Name

Property parent — Control the location of an option in the configuration hierarchy.

## Synopsis

    cdl_option <name> {
        parent <component or package>
        …
    }

## Description

Configuration options live in a hierarchy of packages and components. By default a given option's position in the hierarchy is a simple consequence of its position within the CDL scripts. Packages are generally placed at the top-level of the configuration. Any components or options that are defined at the same level as the `cdl_package` command in a package's top-level CDL script are placed immediately below that package in the hierarchy. Any options or components that are defined in the body of a `cdl_package` or `cdl_component` command, or that are read in as a result of processing a component's script property, will be placed immediately below that package or component in the hierarchy.

In some circumstances it is useful to specify an alternative position in the hierarchy for a given option. For example it is often convenient to re-parent device driver packages below `CYGPKG_IO` in the configuration hierarchy, thus reducing the number of packages at the top level of the hierarchy and making navigation easier. The parent property can be used to achieve this.

The parent property takes a single argument, which should be the name of a package or component. The body of a `cdl_option` or other CDL entity can contain at most one parent property.

Although the parent property affects an option's position in the overall hierarchy and hence whether or not that option is active, a re-parented option still belongs to the package that defines it. By default any `#define's` will be exported to that package's configuration header file. Any compile properties can only reference source files present in that package, and it is not directly possible to cause some file in another package to be built by re-parenting.

> Tip: If an option is re-parented somewhere below another package and that other package is not actually loaded, the option is an orphan and its active/inactive state is undefined. In such cases it is a good idea for the owning package to require the presence of the other one. Unfortunately this technique does not work if a package as a whole is reparented below another one that has not been loaded: the package is orphaned so it may be automatically inactive, and hence any requires properties would have no effect.

> Note: The current configuration tools do not provide a clean syntax for re-parenting immediately below the root of a configuration, alongside the top-level packages. This will be addressed in a future version. Also the handling of orphans needs to be improved.

## Example

    cdl_package CYGPKG_HAL_I386 {
        display       "i386 architecture"
        parent        CYGPKG_HAL
        hardware
        include_dir   cyg/hal
        define_header hal_i386.h
        …
    }

## See Also

Property script , commands `cdl_component` and `cdl_package` .

Prev | Home | Next
no_define | Up | requires