URL https://opencores.org/ocsvn/openrisc/openrisc/trunk
Subversion Repositories openrisc

[/] [openrisc/] [trunk/] [rtos/] [ecos-3.0/] [host/] [libcdl/] [doc/] [reference.sgml] - Blame information for rev 790

Go to most recent revision | Details | Compare with Previous | View Log


 





























 

 

CDL Language Specification
 

This chapter contains reference information for the main &CDL;
commands &cdl-option;, &cdl-component;, &cdl-package; and
&cdl-interface;, followed by the various properties such as
&active-if; and &compile; in alphabetical order.

 

 


&cdl-option;

 

Command &cdl-option;
Define a single configuration option

 


cdl_option <name> {
    …
}


 
Description

The option is the basic unit of configurability. Generally each option
corresponds to a single user choice. Typically there is a certain
amount of information associated with an option to assist the user in
manipulating that option, for example a textual description. There
will also be some limits on the possible values that the user can
choose, so an option may be a simple yes-or-no choice or it may be
something more complicated such as an array size or a device name.
Options may have associated constraints, so if that option is enabled
then certain conditions have to satisfied elsewhere in the
configuration. Options usually have direct consequences such as
preprocessor #define symbols in a configuration
header file.


&cdl-option; is implemented as a Tcl command that takes two arguments,
a name and a body. The name must be a valid C preprocessor identifier:
a sequence of upper or lower case letters, digits or underscores,
starting with a non-digit character; identifiers beginning with an
underscore should normally be avoided because they may clash with
system packages or with identifiers reserved for use by the compiler.
Within a single configuration, names must be unique. If a
configuration contained two packages which defined the same entity
CYGIMP_SOME_OPTION, any references to that entity
in a &requires; property or any other expression
would be ambiguous. It is possible for a given name to be used by two
different packages if those packages should never be loaded into a
single configuration. For example, architectural HAL packages are
allowed to re-use names because a single configuration cannot target
two different architectures. For a recommended naming convention see
.


The second argument to cdl_option is a body of
properties, typically surrounded by braces so that the Tcl interpreter
treats it as a single argument. This body will be processed by a
recursive invocation of the Tcl interpreter, extended with additional
commands for the various properties that are allowed inside a
&cdl-option;. The valid properties are:

 

 
&active-if;

Allow additional control over the active state of this option.

 
&calculated;

The option's value is not directly user-modifiable, it is calculated
using a suitable CDL expression.

 
&compile;

List the source files that should be built if this option is active
and enabled.

 
&default-value;

Provide a default value for this option using a CDL expression.

 
&define;

Specify additional #define symbols that should go
into the owning package's configuration header file.

 
&define-format;

Control how the option's value will appear in the configuration header
file.

 
&define-proc;

Use a fragment of Tcl code to output additional data to
configuration header files.

 
&description;

Provide a textual description for this option.

 
&display;

Provide a short string describing this option.

 
&doc;

The location of on-line documentation for this option.

 
&flavor;

Specify the nature of this option.

 
&if-define;

Output a common preprocessor construct to a configuration header file.

 
&implements;

Enabling this option provides one instance of a more general
interface.

 
&legal-values;

Impose constraints on the possible values for this option.

 
&make;

An additional custom build step associated with this option, resulting
in a target that should not go directly into a library.

 
&make-object;

An additional custom build step associated with this option, resulting
in an object file that should go into a library.

 
&no-define;

Suppress the normal generation of a preprocessor
#define symbol in a configuration header file.

 
&parent;

Control the location of this option in the configuration hierarchy.

 
&requires;

List constraints that the configuration should satisfy if this option is
active and enabled.

 

 

 
Example

cdl_option CYGDBG_INFRA_DEBUG_PRECONDITIONS {
    display       "Preconditions"
    default_value 1
    description   "
        This option allows individual control of preconditions.
        A precondition is one type of assert, which it is
        useful to control separately from more general asserts.
        The function is CYG_PRECONDITION(condition,msg)."
}


 
See Also

Command &cdl-component;,
command &cdl-package;,
command &cdl-interface;.


 

 


 


&cdl-component;

 

Command &cdl-component;
Define a component, a collection of configuration options

 


cdl_component <name> {
    …
}


 
Description

A component is a configuration option that can contain additional
options and sub-components. The body of a &cdl-component; can contain
the same properties as that of a &cdl-option;. There is an additional
property, &script; which allows configuration data to be split into
multiple files. It is also possible for a component body to include
&cdl-component;, &cdl-option; and &cdl-interface; entities that should
go below this component in the configuration hierarchy.


&cdl-component; is implemented as a Tcl command that takes two
arguments, a name and a body. The name must be a valid C preprocessor
identifier: a sequence of upper or lower case letters, digits or
underscores, starting with a non-digit character; identifiers
beginning with an underscore should normally be avoided because they
may clash with system packages or with identifiers reserved for use by
the compiler. Within a single configuration, names must be unique. If
a configuration contained two packages which defined the same entity
CYGIMP_SOME_OPTION, any references to that entity
in a &requires; property or any other expression would be ambiguous.
It is possible for a given name to be used by two different packages
if those packages should never be loaded into a single configuration.
For example, architectural HAL packages are allowed to re-use certain
names because a single configuration cannot target two different
architectures. For a recommended naming convention see 
linkend="package.contents">.


The second argument to &cdl-component; is a body of properties and
other commands, typically surrounded by braces so that the Tcl
interpreter treats it as a single argument. This body will be
processed by a recursive invocation of the Tcl interpreter, extended
with additional commands for the various properties that are allowed
inside a &cdl-component;. The valid commands are:

 

 
&active-if;

Allow additional control over the active state of this component.

 
&calculated;

The component's value is not directly user-modifiable, it is calculated
using a suitable CDL expression.

 
&cdl-component

Define a sub-component.

 
&cdl-interface;

Define an interface which should appear immediately below this
component in the configuration hierarchy.

 
&cdl-option;

Define a configuration option which should appear immediately below
this component in the configuration hierarchy.

 
&compile;

List the source files that should be built if this component is active
and enabled.

 
&default-value;

Provide a default value for this component using a CDL expression.

 
&define;

Specify additional #define symbols that should go
into the owning package's configuration header file.

 
&define-format;

Control how the component's value will appear in the configuration header
file.

 
&define-proc;

Use a fragment of Tcl code to output additional data to
configuration header files.

 
&description;

Provide a textual description for this component.

 
&display;

Provide a short string describing this component.

 
&doc;

The location of on-line documentation for this component.

 
&flavor;

Specify the nature of this component.

 
&if-define;

Output a common preprocessor construct to a configuration header file.

 
&implements;

Enabling this component provides one instance of a more general
interface.

 
&legal-values;

Impose constraints on the possible values for this component.

 
&make;

An additional custom build step associated with this component, resulting
in a target that should not go directly into a library.

 
&make-object;

An additional custom build step associated with this component, resulting
in an object file that should go into a library.

 
&no-define;

Suppress the normal generation of a preprocessor
#define symbol in a configuration header file.

 
&parent;

Control the location of this component in the configuration hierarchy.

 
&requires;

List constraints that the configuration should satisfy if this component is
active and enabled.

 
&script;

Include additional configuration information from another
CDL script

 

 

 
Example


cdl_component CYGDBG_USE_ASSERTS {
    display       "Use asserts"
    default_value 1
    description   "
        If this component is enabled, assertions in the code are
        tested at run-time. Assert functions (CYG_ASSERT()) are
        defined in 'include/cyg/infra/cyg_ass.h' within the 'install'
        tree. If the component is disabled, these result in no
        additional object code and no checking of the asserted
        conditions."
    script        assert.cdl
}



 
See Also

Command &cdl-option;,
command &cdl-package;,
command &cdl-interface;.


 

 


 


&cdl-package;

 

Command &cdl-package;
Define a package, a component that can be distributed

 


cdl_package <name> {
    …
}


 
Description

A package is a unit of distribution. It is also a configuration option
in that users can choose whether or not a particular package is loaded
into the configuration, and which version of that package should be
loaded. It is also a component in that it can contain additional
components and options in a hierarchy.


The top-level &CDL; script for a package should begin with a &cdl-package;
command. This can contain most of the properties that can be used in a
&cdl-option; command, and a number of additional ones which apply to a
package as a whole. It is also possible to include &cdl-component;,
&cdl-interface; and &cdl-option; commands in the body of a package.
However all configuration entities that occur at the top level of the
script containing the &cdl-package; command are automatically placed
below that package in the configuration hierarchy, so putting them
inside the body has no effect.


The following properties cannot be used in the body of a &cdl-package;
command:


 
&flavor;

Packages always have the flavor booldata.

 
&default-value;

The value of a package is its version number. This is specified at the
time the package is loaded into the configuration, and cannot be
calculated afterwards. Typically the most recent version of the
package will be loaded.

 
&legal-values;

The legal values list for a given package is determined by which
versions of that package are installed in the component repository,
and cannot be further constrained in the CDL scripts.

 
&calculated;

The value of a package is always selected at the time that it is
loaded into the configuration, and cannot be re-calculated afterwards.

 
&script;

This would be redundant since the CDL script containing the
&cdl-package; command acts as that package's script.

 

 

&cdl-package; is implemented as a Tcl command that takes two
arguments, a name and a body. The name must be a valid C preprocessor
identifier: a sequence of upper or lower case letters, digits or
underscores, starting with a non-digit character; identifiers
beginning with an underscore should normally be avoided because they
may clash with system packages or with identifiers reserved for use by
the compiler. Packages should always have unique names within a given
component repository. For a recommended naming convention see 
linkend="package.contents">.


The second argument to &cdl-package; is a body of properties and other
commands, typically surrounded by braces so that the Tcl interpreter
treats it as a single argument. This body will be processed by a
recursive invocation of the Tcl interpreter, extended with additional
commands for the various properties that are allowed inside a
&cdl-package;. The valid commands are:

 

 
&active-if;

Allow additional control over the active state of this package.

 
&cdl-component;

Define a component which should appear immediately below this package
in the configuration hierarchy.

 
&cdl-interface;

Define an interface which should appear immediately below this
package in the configuration hierarchy.

 
&cdl-option;

Define an option which should appear immediately below
this package in the configuration hierarchy.

 
&compile;

List the source files that should be built for this package.

 
&define;

Specify additional #define symbols that should go
into the package's configuration header file.

 
&define-format;

Control how the package's value will appear in the global
configuration header file 
class="headerfile">pkgconf/system.h

 
&define-header;

Specify the configuration header file that will be generated for this package.

 
&define-proc;

Use a fragment of Tcl code to output additional data to
configuration header files.

 
&description;

Provide a textual description for this component.

 
&display;

Provide a short string describing this component.

 
&doc;

The location of on-line documentation for this component.

 
&hardware;

This package is tied to specific hardware.

 
&if-define;

Output a common preprocessor construct to a configuration header file.

 
&implements;

Enabling this component provides one instance of a more general
interface.

 
&include-dir;

Specify the desired location of this package's exported header files in
the install tree.

 
&include-files;

List the header files that are exported by this package.

 
&library;

Specify which library should contain the object files
generated by building this package.

 
&make;

An additional custom build step associated with this component, resulting
in a target that should not go directly into a library.

 
&make-object;

An additional custom build step associated with this component, resulting
in an object file that should go into a library.

 
&no-define;

Suppress the normal generation of the package's
#define in the global configuration header file
pkgconf/system.h.

 
&parent;

Control the location of this package in the configuration hierarchy.

 
&requires;

List constraints that the configuration should satisfy if this package is
active.

 
 

 

 
Example

cdl_package CYGPKG_INFRA {
    display       "Infrastructure"
    include_dir   cyg/infra
    description   "
        Common types and useful macros.
        Tracing and assertion facilities.
        Package startup options."
 
    compile startup.cxx prestart.cxx pkgstart.cxx userstart.cxx      \
            dummyxxmain.cxx null.cxx simple.cxx fancy.cxx buffer.cxx \
            diag.cxx tcdiag.cxx memcpy.c memset.c delete.cxx
}
 


 
See Also

Command &cdl-option;,
command &cdl-component;,
command &cdl-interface;.


 

 


 


&cdl-interface;

 

Command &cdl-interface;
Define an interface, functionality that can be provided by
a number of different implementations.

 


cdl_interface <name> {
    …
}


 
Description

An interface is a special type of calculated configuration option.
It provides an abstraction mechanism that is often useful in &CDL;
expressions. As an example, suppose that some package relies on the
presence of code that implements the standard kernel scheduling
interface. However the requirement is no more stringent than this, so
the constraint can be satisfied by the mlqueue scheduler, the bitmap
scheduler, or any additional schedulers that may get implemented in
future. A first attempt at expressing the dependency might be:


    requires CYGSEM_KERNEL_SCHED_MLQUEUE || CYGSEM_KERNEL_SCHED_BITMAP


This constraint is limited, it may need to be changed if a new
scheduler were to be added to the system. Interfaces provide a way of
expressing more general relationships:


    requires CYGINT_KERNEL_SCHEDULER


The interface CYGINT_KERNEL_SCHEDULER is
implemented by both the mlqueue and bitmap
schedulers, and may be implemented by future schedulers as well. The
value of an interface is the number of implementors that are active
and enabled, so in a typical configuration only one scheduler will be
in use and the value of the interface will be 1. If
all schedulers are disabled then the interface will have a value
0 and the &requires; constraint will not be
satisfied.


Some component writers may prefer to use the first &requires;
constraint on the grounds that the code will only have been tested
with the mlqueue and bitmap schedulers and cannot be guaranteed to
work with any new schedulers. Other component writers may take a more
optimistic view and assume that their code will work with any
scheduler until proven otherwise.


Interfaces must be defined in CDL scripts, just like options,
components and packages. This involves the command &cdl-interface;
which takes two arguments, a name and a body. The name must be a valid
C preprocessor identifier: a sequence of upper or lower case letters,
digits or underscores, starting with a non-digit character;
identifiers beginning with an underscore should normally be avoided
because they may clash with system packages or with identifiers
reserved for use by the compiler. Within a single configuration, names
must be unique. If a configuration contained two packages which
defined the same entity CYGIMP_SOME_OPTION, any
references to that entity in a &requires; property or any other
expression would be ambiguous. It is possible for a given name to be
used by two different packages if those packages should never be
loaded into a single configuration. For example, architectural HAL
packages are allowed to re-use names because a single configuration
cannot target two different architectures. For a recommended naming
convention see .


The second argument to &cdl-interface; is a body of properties,
typically surrounded by braces so that the Tcl interpreter treats it
as a single argument. This body will be processed by a recursive
invocation of the Tcl interpreter, extended with additional commands
for the various properties that are allowed inside a &cdl-interface;.
The valid properties are a subset of those for a &cdl-option;.

 

 
&active-if;

Allow additional control over the active state of this interface.

 
&compile;

List the source files that should be built if this interface is active.

 
&define;

Specify additional #define symbols that should go
into the owning package's configuration header file.

 
&define-format;

Control how the interface's value will appear in the configuration header
file.

 
&define-proc;

Use a fragment of Tcl code to output additional data to
configuration header files.

 
&description;

Provide a textual description for this interface.

 
&display;

Provide a short string describing this interface.

 
&doc;

The location of on-line documentation for this interface.

 
&flavor;

Interfaces have the data flavor by default, but
they can also be given the bool or
booldata flavor when necessary. A
bool interface is disabled if there are no active
and enabled implementors, otherwise it is enabled. A
booldata interface is also disabled if there are no
active and enabled implementors, otherwise it is enabled and the data
is a number corresponding to the number of these implementors.

 
&if-define;

Output a common preprocessor construct to a configuration header file.

 
&implements;

If this interface is active it provides one instance of a more general
interface.

 
&legal-values;

Interfaces always have a small numerical value. The &legal-values; can
be used to apply additional constraints such as an upper limit.

 
&make;

An additional custom build step associated with this option, resulting
in a target that should not go directly into a library.

 
&make-object;

An additional custom build step associated with this option, resulting
in an object file that should go into a library.

 
&no-define;

Suppress the normal generation of a preprocessor
#define symbol in a configuration header file.

 
&parent;

Control the location of this option in the configuration hierarchy.

 
&requires;

List constraints that the configuration should satisfy if this option is
active and enabled.

 

 

A number of properties are not applicable to interfaces:


 
&calculated;

Interfaces are always calculated, based on the number of active and
enabled entities that implement the interface.

 
&default-value;

Interface values are calculated so a &default-value; property would be
meaningless.

 

 

Interfaces are not containers, so they cannot hold other entities such
as options or components.


A commonly used constraint on interface values takes the form:


    requires CYGINT_KERNEL_SCHEDULER == 1


This constraint specifies that there can be only one scheduler in the
system. In some circumstances it is possible for the configuration
tools to detect this pattern and act accordingly, so for example
enabling the bitmap scheduler would automatically disable the mlqueue
scheduler.

 

 
Example

cdl_interface CYGINT_KERNEL_SCHEDULER {
    display  "Number of schedulers in this configuration"
    requires 1 == CYGINT_KERNEL_SCHEDULER
}


 
See Also

Property &implements;,
command &cdl-option;.
command &cdl-component;,
command &cdl-package;.


 

 

 

 


&active-if;

 

Property &active-if;
Allow additional control over the active state of an
option or other CDL entity.

 


cdl_option <name> {
    active_if <condition>
    …
}


 
Description

Configuration options or other entities may be either active or
inactive. Typically this is controlled by the option's location in the
overall hierarchy. Consider the option
CYGDBG_INFRA_DEBUG_PRECONDITIONS, which exists
below the component CYGDBG_USE_ASSERT. If the whole
component is disabled then the options it contains are inactive: there
is no point in enabling preconditions unless there is generic
assertion support; any &requires; constraints associated with
preconditions are irrelevant; any &compile; property or other
build-related property is ignored.


In some cases the hierarchy does not provide sufficient control over
whether or not a particular option should be active. For example, the
math library could have support for floating point exceptions which
is only worthwhile if the hardware implements appropriate
functionality, as specified by the architectural HAL. The relevant
math library configuration options should remain below the
CYGPKG_LIBM package in the overall hierarchy, but
should be inactive unless there is appropriate hardware support. In
cases like this an &active-if; property is appropriate.


Another common use of &active-if; properties is to avoid excessive
nesting in the configuration hierarchy. If some option B is only
relevant if option A is enabled, it is possible to turn A into a
component that contains B. However adding another level to the
hierarchy for a component which will contain just one entry may be
considered excessive. In such cases it is possible for B to have an
&active-if; dependency on A.


&active-if; takes a goal expression as argument. For details of goal
expression syntax see . In
most cases the goal expression will be very simple, often involving
just one other option, but more complicated expressions can be used
when appropriate. It is also possible to have multiple &active-if;
conditions in a single option, in which case all of the conditions
have to be satisfied if the option is to be active.


The &active-if; and &requires; properties have certain similarities,
but they serve a different purpose. Suppose there are two options A
and B, and option B relies on functionality provided by A. This could
be expressed as either active_if A or as
requires A. The points to note are:


 

If active_if A is used and A is disabled or
inactive, then graphical tools will generally prevent any attempt at
modifying B. For example the text for B could be grayed out, and the
associated checkbutton (if B is a boolean option) would be disabled.
If the user needs the functionality provided by option B then it is
necessary to go to option A first and manipulate it appropriately.

 

If requires A is used and A is disabled or
inactive, graphical tools will still allow B to be manipulated and
enabled. This would result in a new conflict which may get resolved
automatically or which may need user intervention.

 

If there are hardware dependencies then an &active-if; condition is
usually the preferred approach. There is no point in allowing the user
to manipulate a configuration option if the corresponding
functionality cannot possibly work on the currently-selected hardware.
Much the same argument applies to coarse-grained dependencies, for
example if an option depends on the presence of a TCP/IP stack then an
active_if CYGPKG_NET condition is appropriate:
it may be possible to satisfy the condition, but it requires the
fairly drastic step of loading another package; further more, if the
user wanted a TCP/IP stack in the configuration then it would probably
have been loaded already. 
 

If option B exists to provide additional debugging information about
the functionality provided by A then again an &active-if; constraint
is appropriate. There is no point in letting users enable extra
debugging facilities for a feature that is not actually present.

 

The configuration system's inference engine will cope equally well
with &active-if; and &requires; properties. Suppose there is a
conflict because some third option depends on B. If B is
active_if A then the inference engine will
attempt to make A active and enabled, and then to enable B if
necessary. If B requires A then the inference
engine will attempt to enable B and resolve the resulting conflict by
causing A to be both active and enabled. Although the inference occurs
in a different order, in most cases the effect will be the same.

 

 

 
Example

# Do not provide extra semaphore debugging if there are no semaphores
cdl_option CYGDBG_KERNEL_INSTRUMENT_BINSEM {
    active_if CYGPKG_KERNEL_SYNCH
    …
}
 
# Avoid another level in the configuration hierarchy
cdl_option CYGSEM_KERNEL_SYNCH_MUTEX_PRIORITY_INHERITANCE_SIMPLE_RELAY {
    active_if CYGSEM_KERNEL_SYNCH_MUTEX_PRIORITY_INHERITANCE_SIMPLE
    …
}
 
# Functionality that is only relevant if another package is loaded
cdl_option CYGSEM_START_UITRON_COMPATIBILITY {
    active_if CYGPKG_UITRON
    …
}
 
# Check that the hardware or HAL provide the appropriate functionality
cdl_option CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT {
    active_if CYGINT_HAL_DEBUG_GDB_STUBS_BREAK
    …
}


 
See Also

Property &requires;.


 

 


 


&calculated;

 

Property &calculated;
Used if the current option's value is not user-modifiable,
but is calculated using a suitable CDL expression.

 


cdl_option <name> {
    calculated <expression>
    …
}


 
Description

In some cases it is useful to have a configuration option whose value
cannot be modified directly by the user. This can be achieved using a
&calculated;, which takes a CDL expression as argument (see 
linkend="language.expression"> for a description of expression
syntax). The configuration system evaluates the expression when the
current package is loaded and whenever there is a change to any other
option referenced in the expression. The result depends on the
option's flavor:

 

 
flavor none

Options with this flavor have no value, so the &calculated;
property is not applicable.

 
flavor bool

If the expression evaluates to a non-zero result the option is
enabled, otherwise it is disabled.

 
flavor booldata

If the result of evaluating the expression is zero then the option is
disabled, otherwise the option is enabled and its value is the result.

 
flavor data

The value of the option is the result of evaluating the expression.

 

 

There are a number of valid uses for calculated options, and there are
also many cases where some other CDL facility would be more
appropriate. Valid uses of calculated options include the following:


 

On some target hardware a particular feature may be user-configurable,
while on other targets it is fixed. For example some processors can
operate in either big-endian or little-endian mode, while other
processors do not provide any choice. It is possible to have an
option CYGARC_BIGENDIAN which is calculated in
some architectural HAL packages but user-modifiable in others.

 

Calculated options can provide an alternative way for one package to
affect the behavior of another one. Suppose a package may provide two
possible implementations, a preferred one involving self-modifying
code and a slower alternative. If the system involves a ROM bootstrap
then the slower alternative must be used, but it would be
inappropriate to modify the startup option in every HAL to impose
constraints on this package. Instead it is possible to have a
calculated option whose value is
{ CYG_HAL_STARTUP == "ROM" },
and which has appropriate consequences. Arguably this is a spurious
example, and it should be a user choice whether or not to use
self-modifying code with a &default-value; based on
CYG_HAL_STARTUP, but that is for the component
writer to decide.

 

Sometimes it should be possible to perform a particular test at
compile-time, for example by using a C preprocessor
#if construct. However the preprocessor has only
limited functionality, for example it cannot perform string
comparisons. CDL expressions are more powerful.

 

Occasionally a particular sub-expression may occur multiple times in
a CDL script. If the sub-expression is sufficiently complex then it
may be worthwhile to have a calculated option whose value is the
sub-expression, and then reference that calculated option in the
appropriate places.

 

 

Alternatives to using calculated options include the following:


 

CDL interfaces are a form of
calculated option intended as an abstraction mechanism. An interface
can be used to express the concept of any
scheduler, as opposed to a specific one such as the bitmap scheduler.

 

If a calculated option would serve only to add additional information
to a configuration header file, it may be possible to achieve the same
effect using a &define-proc
property or one of the other properties related to header file
generation.

 

 


If the first entry in a &calculated; expression is a negative
number, for example calculated -1 then this
can be misinterpreted as an option instead of as part of the
expression. Currently the &calculated; property does not take any
options, but this may change in future. Option processing halts at the
sequence --, so the desired value can be expressed
safely using
calculated -- -1


 


Some of the CDL scripts in current &eCos; releases make excessive use
of calculated options. This is partly because the recommended
alternatives were not always available at the time the scripts were
written. It is also partly because there is still some missing
functionality, for example &define-proc; properties cannot yet access
the configuration data so it may be necessary to use &calculated;
properties to access the data and perform the desired manipulation via
a &CDL; expression. New scripts should use calculated options only in
accordance with the guidelines.


 


For options with the booldata flavor the current CDL syntax does not
allow the enabled flag and the value to be calculated separately.
Functionality to permit this may be added in a future release.


 


It has been suggested that having options which are not
user-modifiable is potentially confusing, and that a top-level
cdl_constant command should be added to the
language instead of or in addition to the &calculated; property. Such
a change is under consideration. However because the value of a
calculated option can depend on other options, it is not necessarily
constant.


 

 
Example

# A constant on some target hardware, perhaps user-modifiable on other
# targets.
cdl_option CYGNUM_HAL_RTC_PERIOD {
    display       "Real-time clock period"
    flavor        data
    calculated    12500
}


 
See Also

Properties &default-value;,
&flavor; and
&legal-values;,


 

 


 


&compile;

 

Property &compile;
List the source files that should be built if this option
is active and enabled.

 


cdl_option <name> {
    compile [-library=libxxx.a] <list of files>
    …
}


 
Description

The &compile; property allows component developers to specify source
files which should be compiled and added to one of the target
libraries. Usually each source file will end up the library
libtarget.a. It is possible for component writers
to specify an alternative library for an entire package using the
&library; property. Alternatively
the desired library can be specified on the &compile; line itself. For
example, to add a particular source file to the
libextras.a library the following could be used:


cdl_package CYGPKG_IO_SERIAL {
    …
    compile -library=libextras.a common/tty.c
}


Details of the build process including such issues as compiler flags
and the order in which things happen can be found in
.


&compile; properties can occur in any of &cdl-option;,
&cdl-component;, &cdl-package; or &cdl-interface;. A &compile;
property has effect if and only if the entity that contains it is
active and enabled. Typically the body of a &cdl-package; will define
any source files that need to be built irrespective of individual
options, and each &cdl-component;, &cdl-option;, and &cdl-interface;
will define source files that are more specific. A single &compile;
property can list any number of source files, all destined for the
same library. A &cdl-option; or other entity can contain multiple
&compile; properties, each of which can specify a different library.
It is possible for a given source file to be specified in &compile;
properties for several different options, in which case the source
file will get built if any of these options are active and enabled.


If the package follows the directory
layout conventions then the configuration tools will search for
the specified source files first in the
src subdirectory of the
package, then relative to the package directory itself.

 


A shortcoming of the current specification of &compile; properties is
that there is no easy way to specify source files that should be built
unless an option is enabled. It would sometimes be useful to be able
to say: “if option A is enabled then compile
file x.c, otherwise compile file
y.c. There are two simple ways of achieving this:



Always compile y.c, typically by listing it in
the body of the &cdl-package;, but use
#ifndef A to produce an empty object file if
option A is not enabled. This has the big
disadvantage that the file always gets compiled and hence for some
configurations builds will take longer than necessary.


Use a &calculated; option whose value is !A, and
have a compile y.c property in its body. This
has the big disadvantage of adding another calculated option to the
configuration.



It is likely that this will be resolved in the future, possibly by
using some sort of expression as the argument to a &compile; property.


 


Currently it is not possible to control the priority of a &compile;
property, in other words the order in which a file gets compiled
relative to other build steps. This functionality might prove useful
for complicated packages and should be added.



 
Example

cdl_package CYGPKG_INFRA {
    display       "Infrastructure"
    include_dir   cyg/infra
    description   "
        Common types and useful macros.
        Tracing and assertion facilities.
        Package startup options."
 
    compile startup.cxx prestart.cxx pkgstart.cxx userstart.cxx \
            dummyxxmain.cxx memcpy.c memset.c delete.cxx \
            diag.cxx tcdiag.cxx
}


 
See Also

Properties make,
make_object and
library.


 

 


 


&default-value;

 

Property &default-value;
Provide a default value for this option using a CDL expression.

 


cdl_option <name> {
    default_value <expression>
    …
}


 
Description

The &default-value; property allows the initial value of a
configuration option to depend on other configuration options. The
arguments to the property should be a &CDL; expression, see
 for the syntactic details.
In many cases a simple constant value will suffice, for example:


cdl_component CYGPKG_KERNEL_EXCEPTIONS {
    …
    default_value 1
 
    cdl_option CYGSEM_KERNEL_EXCEPTIONS_DECODE {
        …
        default_value 0
    }
}


However it is also possible for an option's default value to depend on
other options. For example the common HAL package provides some
support functions that are needed by the &eCos; kernel, but are
unlikely to be useful if the kernel is not being used. This
relationship can be expressed using:


cdl_option CYGFUN_HAL_COMMON_KERNEL_SUPPORT {
    ...
    default_value CYGPKG_KERNEL
}


If the kernel is loaded then this HAL option is automatically enabled,
although the user can still disable it explicitly should this prove
necessary. If the kernel is not loaded then the option is disabled,
although it can still be enabled by the user if desired.
&default-value; expressions can be more complicated than this if
appropriate, and provide a very powerful facility for component
writers who want their code to “just do the right thing”
in a wide variety of configurations.


The &CDL; configuration system evaluates the &default-value;
expression when the current package is loaded and whenever there is a
change to any other option referenced in the expression. The result
depends on the option's flavor:

 

 
flavor none

Options with this flavor have no value, so the &default-value;
property is not applicable.

 
flavor bool

If the expression evaluates to a non-zero result the option is
enabled by default, otherwise it is disabled.

 
flavor booldata

If the result of evaluating the expression is zero then the option is
disabled, otherwise the option is enabled and its value is the result.

 
flavor data

The default value of the option is the result of evaluating the
expression.

 

 

A &cdl-option; or other entity can have at most one &default-value;
property, and it is illegal to have both a &calculated; and a
&default-value; property in one body. If an option does not have
either a &default-value; or a &calculated; property and it does not
have the flavor none then the configuration tools
will assume a default value expression of 0.


On occasion it is useful to have a configuration option
A which has both a &requires; constraint on some
other option B and a &default-value; expression of
B. If option B is not enabled
then A will also be disabled by default and no
conflict arises. If B is enabled then
A also becomes enabled and again no conflict
arises. If a user attempts to enable B but not
A then there will be a conflict. Users should be
able to deduce that the two options are closely interlinked and should
not be manipulated independently except in very unusual circumstances.

 


If the first entry in a &default-value; expression is a negative
number, for example default_value -1 then this
can be misinterpreted as an option instead of as part of the
expression. Currently the &default-value; property does not take any
options, but this may change in future. Option processing halts at the
sequence --, so the desired value can be expressed
safely using
default_value -- -1


 


In many cases it would be useful to calculate default values using
some global preferences, for example:


cdl_option CYGIMP_LIBC_STRING_PREFER_SMALL_TO_FAST {
    …
    default_value CYGGLO_CODESIZE > CYGGLO_SPEED
}


Such global preference options do not yet exist, but are likely to be
added in a future version.


 


For options with the booldata flavor the current syntax does not allow
the default values of the enabled flag and the value to be controlled
separately. Functionality to permit this may be added in a future
release.


 

 
Example

cdl_option CYGDBG_HAL_DEBUG_GDB_THREAD_SUPPORT {
    display       "Include GDB multi-threading debug support"
    requires      CYGDBG_KERNEL_DEBUG_GDB_THREAD_SUPPORT
    default_value CYGDBG_KERNEL_DEBUG_GDB_THREAD_SUPPORT
    description   "
        This option enables some extra HAL code which is needed
        to support multi-threaded source level debugging."
}


 
See Also

Properties &calculated;,
&flavor; and
&legal-values;.


 

 


 


&define;

 

Property &define;
Specify additional #define symbols that
should go into the owning package's configuration header file.

 


cdl_option <name> {
    define [-file=<filename>] [-format=<format>] <symbol>
    …
}


 
Description

Normally the configuration system generates a single
#define for each option that is active and enabled,
with the defined symbol being the name of the option. These
#define's go to the package's own configuration
header file, for example pkgconf/kernel.h
for kernel configuration options. For the majority of options this is
sufficient. Sometimes it is useful to have more control over which
#define's get generated.


The &define; property can be used to generate an additional
#define if the option is both active and enabled,
for example:


cdl_option CYGNUM_LIBC_STDIO_FOPEN_MAX {
    …
    define FOPEN_MAX
}


If this option is given the value 40 then the following
#define's will be generated in the configuration
header pkgconf/libc.h:


#define CYGNUM_LIBC_STDIO_FOPEN_MAX 40
#define FOPEN_MAX 40


The default #define can be suppressed if desired
using the &no-define; property. This is useful if the symbol should
only be defined in
pkgconf/system.h and not in
the package's own configuration header file. The value that will be
used for this #define is the same as for the
default one, and depends on the option's flavor as follows:

 

 
flavor none

Options with this flavor are always enabled and have no value, so the
constant 1 will be used.

 
flavor bool

If the option is disabled then no #define will be
generated. Otherwise the constant 1 will be used.

 
flavor booldata

If the option is disabled then no #define will be
generated. Otherwise the option's current value will be used.

 
flavor data

The option's current value will be used.

 

 

For active options with the data flavor, and for
active and enabled options with the booldata
flavor, either one or two #define's will be
generated. These take the following forms:


#define <symbol> <value>
#define <symbol>_<value>


For the first #define it is possible to control the
format used for the value using a
-format=<format> option. For example, the
following can be used to output some configuration data as a C string:


cdl_option <name> {
    …
    define -format="\\\"%s\\\"" <symbol>
}


The implementation of this facility involves concatenating the
Tcl command format, the format string, and the
string representation of the option's value, and evaluating this in a
Tcl interpreter. Therefore the format string will be processed twice
by a Tcl parser, and appropriate care has to be taken with quoting.


The second #define will be generated only if is a
valid C preprocessor macro symbol. By default the symbols generated by
&define; properties will end up in the package's own configuration
header file. The -file option can be used to
specify an alternative destination. At the time of writing the only
valid alternative definition is -file=system.h,
which will send the output to the global configuration header file
pkgconf/system.h.



Care has to be taken with the -format option.
Because the Tcl interpreter's format command is
used, this property is subject to any problems with the implementation
of this in the Tcl library. Generally there should be no problems with
string data or with integers up to 32 bits, but there may well be
problems if 64-bit data is involved. This issue may be addressed in a
future release.



 
Example

cdl_component CYG_HAL_STARTUP {
    display       "Startup type"
    flavor        data
    legal_values  {"RAM" "ROM" }
    default_value {"RAM"}
    no_define
    define -file=system.h CYG_HAL_STARTUP
    …
}


 
See Also

Properties &define-format;,
&define-header;,
&define-proc;,
&if-define; and
&no-define;.


 

 


 


&define-format;

 

Property &define-format;
Control how an option's value will appear in the
configuration header file.

 


cdl_option <name> {
    define_format <format string>
    …
}


 
Description

For active options with the data flavor, and for
active and enabled options with the booldata
flavor, the configuration tools will normally generate two
#define's in the package's configuration header
file. These take the following forms:


#define <name> <value>
#define <name>_<value>


The &define-format; property can be used to control exactly what
appears as the value for the first of these
#define's. For example, the following can be used
to output some configuration data as a C string:


cdl_option <name> {
    …
    define -format="\\\"%s\\\"" <symbol>
}


The implementation of &define-format; involves concatenating the Tcl
command format, the format string, and the string
representation of the option's value, and evaluating this in a Tcl
interpreter. Therefore the format string will be processed twice by a
Tcl parser, and appropriate care has to be taken with quoting.


The second #define will be generated only if is a
valid C preprocessor macro symbol, and is not affected by the
&define-format; property. Also, the property is only relevant for
options with the data or
booldata flavor, and cannot be used in
conjunction with the &no-define; property since it makes no sense to
specify the format if no #define is generated.



Because the Tcl interpreter's format command is
used, this property is subject to any problems with the implementation
of this in the Tcl library. Generally there should be no problems with
string data or with integers up to 32 bits, but there may well be
problems if 64-bit data is involved. This issue may be addressed in a
future release.


 

 
Example

cdl_option CYGNUM_UITRON_VER_ID     {
    display       "OS identification"
    flavor        data
    legal_values  0 to 0xFFFF
    default_value 0
    define_format "0x%04x"
    description   "
        This value is returned in the 'id'
        field of the T_VER structure in
        response to a get_ver() system call."
}


 
See Also

Properties &define;,
&define-header;,
&define-proc;,
&if-define; and
&no-define;.


 

 


 


&define-header;

 

Property &define-header;
Specify the  configuration header file that
will be generated for a given package.

 


cdl_package <name> {
    define_header <file name>
    …
}


 
Description

When the configuration tools generate a build tree, one of the steps
is to output each package's configuration data to a header file. For
example the kernel's configuration data gets output to
pkgconf/kernel.h. This allows
each package's source code to #include the
appropriate header file and adapt to the choices made by the user.


By default the configuration tools will synthesize a file name from
the package name. This involves removing any prefix such as
CYGPKG_, up to and including the first underscore,
and then converting the remainder of the name to lower case. In some
cases it may be desirable to use a different header file, for example
an existing package may have been ported to &eCos; and the source code
may already #include a particular file for
configuration data. In such cases a &define-header; property can be
used to specify an alternative filename.


The &define-header; property can only be used in the body of a
&cdl-package; command. It applies to a package as a whole and cannot
be used at a finer grain. The name specified in a &define-header;
property will always be interpreted as relative to the
include/pkgconf sub-directory
of the install tree.



For hardware-specific packages such as device drivers and HAL
packages, the current scheme of generating a configuration header file
name based on the package name may be abandoned. Instead all hardware
packages would send their configuration data to a single header file,
pkgconf/hardware.h. This would
make it easier for code to obtain details of the current hardware, but
obviously there are compatibility issues. For now it is recommended
that all hardware packages specify their configuration header file
explicitly.



 
Example

cdl_package CYGPKG_HAL_ARM {
    display       "ARM architecture"
    parent        CYGPKG_HAL
    hardware
    include_dir   cyg/hal
    define_header hal_arm.h
    …
}


 
See Also

Properties &define;,
&define-format;,
&define-proc;,
&if-define;,
&no-define; and
&hardware;,


 

 


 


&define-proc;

 

Property &define-proc;
Use a fragment of Tcl code to output additional data to
configuration header files.

 


cdl_option <name> {
    define_proc <Tcl script>
    …
}


 
Description

For most configuration options it is sufficient to have an entry in
the configuration header file of the form:


#define <name> <value>


In some cases it is desirable to perform some more complicated
processing when generating a configuration header file. There are a
number of CDL properties for this, including &define-format; and
&if-define;. The most flexible is &define-proc;: this allows the
component writer to specify a Tcl script that gets invoked whenever
the configuration system generates the header file for the owning
package. The script can output anything to the header file, for
example it could generate a C data structure based on various
configuration values.


At the point that the &define-proc; script is invoked there will be
two channels to open files, accessible via Tcl variables:
cdl_header is a channel to the current package's
own header file for example
pkgconf/kernel.h;
cdl_system_header is a channel to the global
configuration file
pkgconf/system.h. A typical
&define-proc; script will use the puts command to
output data to one of these channels.


&define-proc; properties only take effect if the current option is
active and enabled. The default behavior of the configuration system
for an option with the bool flavor corresponds to
the following &define-proc;:


    cdl_option XXX {
        …
        define_proc {
            puts $cdl_header "#define XXX 1"
        }
}



In the current implementation it is not possible for a &define-proc;
property to examine the current values of various configuration
options and adapt accordingly. This is a major limitation, and will be
addressed in future versions of the configuration tools.


 

 
Example

cdl_package CYGPKG_HAL_ARM_PID {
    display       "ARM PID evaluation board"
    parent        CYGPKG_HAL_ARM
    define_header hal_arm_pid.h
    include_dir   cyg/hal
    hardware
 
    define_proc {
        puts $::cdl_system_header "#define CYGBLD_HAL_TARGET_H   <pkgconf/hal_arm.h>"
        puts $::cdl_system_header "#define CYGBLD_HAL_PLATFORM_H <pkgconf/hal_arm_pid.h>"
        puts $::cdl_header ""
        puts $::cdl_header "#define HAL_PLATFORM_CPU    \"ARM 7TDMI\""
        puts $::cdl_header "#define HAL_PLATFORM_BOARD  \"PID\""
        puts $::cdl_header "#define HAL_PLATFORM_EXTRA  \"\""
        puts $::cdl_header ""
    }
    …
}


 
See Also

Properties &define;,
&define-format;,
&define-header;,
&if-define; and
&no-define;.


 

 


 


&description;

 

Property &description;
Provide a textual description for an option.

 


cdl_option <name> {
    description <text>
    …
}


 
Description

Users can only be expected to manipulate configuration options
sensibly if they are given sufficient information about these options.
There are three properties which serve to explain an option in plain
text: the &display; property gives a textual alias for an option,
which is usually more comprehensible than something like
CYGPKG_LIBC_TIME_ZONES; the &description; property
gives a longer description, typically a paragraph or so; the &doc;
property specifies the location of additional on-line documentation
related to a configuration option. In the context of a graphical tool
the &display; string will be the primary way for users to identify
configuration options; the &description; paragraph will be visible
whenever the option is selected; the on-line documentation will only
be accessed when the user explicitly requests it.


At present there is no way of providing any sort of formatting mark-up
in a description. It is possible that future versions of the
configuration tools will provide some control over the way the
description text gets rendered.


 
Example

cdl_option CYGDBG_INFRA_DEBUG_TRACE_MESSAGE {
    display       "Use trace text"
    default_value 1
    description   "
        All trace calls within eCos contain a text message
        which should give some information about the circumstances.
        These text messages will end up being embedded in the
        application image and hence there is a significant penalty
        in terms of image size.
        It is possible to suppress the use of these messages by
        disabling this option.
        This results in smaller code size, but there is less
        human-readable information available in the trace output,
        possibly only filenames and line numbers."
}


 
See Also

Properties &display; and
&doc;.


 

 


 


&display;

 

Property &display;
Provide a short string describing this option.

 


cdl_option <name> {
    display <string>
    …
}


 
Description

Users can only be expected to manipulate configuration options
sensibly if they are given sufficient information about these options.
There are three properties which serve to explain an option in plain
text: the &display; property gives a textual alias for an option,
which is usually more comprehensible than something like
CYGPKG_LIBC_TIME_ZONES; the &description; property
gives a longer description, typically a paragraph or so; the &doc;
property specifies the location of additional on-line documentation
related to a configuration option. In the context of a graphical tool
the &display; string will be the primary way for users to identify
configuration options; the &description; paragraph will be visible
whenever the option is selected; the on-line documentation will only
be accessed when the user explicitly requests it.


 
Example

cdl_option CYGNUM_KERNEL_SYNCH_MBOX_QUEUE_SIZE {
    display       "Message box queue size"
    flavor        data
    legal_values  1 to 65535
    default_value 10
    description   "
        This configuration option controls the number of messages
        that can be queued in a message box before a non-blocking
        put() operation will fail or a blocking put() operation will
        block. The cost in memory is one pointer per message box for
        each possible message."
}


 
See Also

Properties &description; and
&doc;.


 

 


 


&doc;

 

Property &doc;
The location of online-documentation for a configuration option.

 


cdl_option <name> {
    doc <URL;>
    …
}


 
Description

Users can only be expected to manipulate configuration options
sensibly if they are given sufficient information about these options.
There are three properties which serve to explain an option in plain
text: the &display; property gives a textual alias for an option,
which is usually more comprehensible than something like
CYGPKG_LIBC_TIME_ZONES; the &description; property
gives a longer description, typically a paragraph or so; the &doc;
property specifies the location of additional on-line documentation
related to a configuration option. In the context of a graphical tool
the &display; string will be the primary way for users to identify
configuration options; the &description; paragraph will be visible
whenever the option is selected; the on-line documentation will only
be accessed when the user explicitly requests it.


The documentation may be an absolute URL, but more generally the
on-line documentation will be shipped with the package and can be
accessed via a relative URL. If the package follows the 
linkend="package.hierarchy">directory layout conventions then
the configuration tools will search for the specified html file
first in the doc subdirectory
of the package, then relative to the package directory itself. The URL
may contain a # character to specify an anchor
within a page.



At the time of writing the &eCos; packages in the standard
distribution do not conform to the directory layout conventions when
it comes to the documentation. Instead of organizing the documentation
on a per-package basis and placing it in the corresponding
doc sub-directories, all the
documentation is kept in a central location. This should get addressed
in a future release of the system. Third party component writers
should follow the layout conventions.



 
Example

cdl_package CYGPKG_KERNEL {
    display       "eCos kernel"
    doc           ref/ecos-ref.4.html
    include_dir   cyg/kernel
    description   "
        This package contains the core functionality of the eCos
        kernel. It relies on functionality provided by various HAL
        packages and by the eCos infrastructure. In turn the eCos
        kernel provides support for other packages such as the device
        drivers and the uITRON compatibility layer."
    …
}


 
See Also

Properties &description; and
&display;.


 

 


 


&flavor;

 

Property &flavor;
Specify the nature of a configuration option.

 


cdl_option <name> {
    flavor <flavor>
    …
}


 
Description

The state of a &CDL; configuration option is a somewhat complicated
concept. This state determines what happens when a build tree is
generated: it controls what files get built and what
#define's end up in configuration header files. The
state also controls the values used during expression evaluation. The
key concepts are:



An option may or may not be loaded into the current configuration.
However it is still possible for packages to reference options which
are not loaded in a &requires; constraint or other expression. If an
option is not loaded then it will have no direct effect on the build
process, and 0 will be used for expression
evaluation.

 

Even if an option is loaded it may still be inactive. Usually this is
controlled by the option's location in the configuration hierarchy. If
an option's parent is active and enabled then the option will normally
be active. If the parent is either inactive or disabled then the
option will be inactive. For example, if kernel timeslicing is diabled
then the option CYGNUM_KERNEL_SCHED_TIMESLICE_TICKS
is irrelevant and must have no effect. The &active-if; property can be
used to specify additional constraints. If an option is inactive then
it will have no direct effect on the build process, in other words it
will not cause any files to get built or #define's
to be generated. For the purposes of expression evaluation an inactive
option has a value of 0.

 

An option may be enabled or disabled. Most options are boolean in
nature, for example a particular function may get inlined or it may
involve a full procedure call. If an option is disabled then it has no
direct effect on the build process, and for the purposes of expression
evaluation it has a value of 0.


An option may also have additional data associated with it, for
example a numerical value used to control the size of an array.



Most options are boolean in nature and do not have any additional
associated data. For some options only the data part makes sense and
users should be unable to manipulate the enabled/disabled part of the
state. For a comparatively small number of options it makes sense to
have the ability to disable that option or to enable it and associate
data as well. Finally, when constructing an option hierarchy it is
occasionally useful to have entities which serve only as placeholders.
The &flavor; property can be used to control all this. There are four
possible values. It should be noted that the active or inactive state
of an option takes priority over the flavor: if an option is inactive
then no #define's will be generated and any
build-related properties such as &compile; will be ignored.

 

 
flavor none

The none is intended primarily for placeholder
components in the hierarchy, although it can be used for other
purposes. Options with this flavor are always enabled and do not have
any additional data associated with them, so there is no way for users
to modify the option. For the purposes of expression evaluation an
option with flavor none always has the value
1. Normal #define processing
will take place, so typically a single #define will
be generated using the option name and a value of
1. Similarly build-related properties such as
&compile; will take effect.

 
flavor bool

Boolean options can be either enabled or disabled, and there is no
additional data associated with them. If a boolean option is disabled
then no #define will be generated and any
build-related properties such as &compile; will be ignored. For the
purposes of expression evaluation a disabled option has the value
0. If a boolean option is enabled then normal
#define processing will take place, all
build-related properties take effect, and the option's value will be
1.

 
flavor data

Options with this flavor are always enabled, and have some additional
data associated with them which can be edited by the user. This data
can be any sequence of characters, although in practice the
&legal-values; property will often be used to impose constraints. In
appropriate contexts such as expressions the configuration tools will
attempt to interpret the data as integer or floating point numbers.
Since an option with the data flavor cannot be
disabled, normal #define processing takes place and
the data will be used for the value. Similarly all build-related
properties take effect, and the option's value for the purposes of
expression evaluation is the data.

 
flavor booldata

This combines the bool and data
flavors. The option may be enabled or disabled, and in addition the
option has some associated data. If the option is disabled then no
#define will be generated, the build-related
properties have no effect, and for the purposes of expression
evaluation the option's value is 0. If the option
is enabled then a #define will be generated using
the data as the value, all build-related properties take effect, and
the option's value for the purposes of expression evaluation is the
data. If 0 is legal data then it is not possible to
distinguish this case from the option being disabled or inactive.

 

 

Options and components have the bool flavor by
default, but this can be changed as desired. Packages always have the
booldata flavor, and this cannot be changed.
Interfaces have the data flavor by default, since
the value of an interface is a count of the number of active and
enabled interfaces, but they can be given the bool
or booldata flavors.

 


The expression syntax needs to be extended to allow the loaded,
active, enabled and data aspects of an option's state to be examined
individually. This would allow component writers to distinguish
between a disabled booldata option and an enabled
one which has a value of 0. Such an enhancement to
the expression syntax may also prove useful in other circumstances.


 

 
Example

 
cdl_component CYGPKG_LIBM_COMPATIBILITY {
 
    cdl_component CYGNUM_LIBM_COMPATIBILITY {
        flavor booldata
        …
 
        cdl_option CYGNUM_LIBM_COMPAT_DEFAULT {
            flavor data
            …
        }
    }
 
    …
}
 
cdl_component CYGPKG_LIBM_TRACE {
    flavor        bool
    …
}


 
See Also

Properties &calculated;,
&default-value; and
&legal-values;,


 

 


 


&hardware;

 

Property &hardware;
Specify that a package is tied to specific hardware.

 


cdl_option <name> {
    active_if <condition>
    …
}


 
Description

Some packages such as device drivers and HAL packages are
hardware-specific, and generally it makes no sense to add such
packages to a configuration unless the corresponding hardware is
present on your target system. Typically hardware package selection
happens automatically when you select your target. The &hardware;
property can be used in the body of a &cdl-package; command to
indicate that the package is hardware-specific.

 


At the time of writing the &hardware; property is largely ignored by
the configuration tools, but this may change in future. Amongst other
possible changes, for hardware-specific packages such as device
drivers and HAL packages, the current scheme of generating a
configuration header file name based purely on the package name may be
abandoned. Instead all hardware packages would send their
configuration data to a single header file, 
class="HeaderFile">pkgconf/hardware.h. This would make it
easier for code to obtain details of the current hardware, but
obviously there are compatibility issues. For now it is recommended
that all hardware packages specify their configuration header file
explicitly.



 
Example

cdl_package CYGPKG_HAL_ARM {
    display       "ARM architecture"
    parent        CYGPKG_HAL
    hardware
    include_dir   cyg/hal
    define_header hal_arm.h
    …
}


 
See Also

Property &define-header;, and
command &cdl-package;.


 

 


 


&if-define;

 

Property &if-define;
Output a common preprocessor construct to a configuration
header file.

 


cdl_option <name> {
    if_define [-file=<filename>] <symbol1> <symbol2>
    …
}


 
Description

The purpose of the &if-define; property is best explained by an
example. Suppose you want finer-grained control over assertions, say
on a per-package or even a per-file basis rather than globally. The
assertion macros can be defined by an exported header file in an
infrastructure package, using code like the following:


#ifdef CYGDBG_USE_ASSERTS
# define CYG_ASSERT( _bool_, _msg_ )    \
        CYG_MACRO_START                 \
        if ( ! ( _bool_ ) )             \
            CYG_ASSERT_DOCALL( _msg_ ); \
        CYG_MACRO_END
#else
# define CYG_ASSERT( _bool_, _msg_ ) CYG_EMPTY_STATEMENT
#endif


Assuming this header file is #include'd directly or
indirectly by any code which may need to be built with assertions
enabled, the challenge is now to control whether or not
CYGDBG_USE_ASSERTS is defined for any given source
file. This is the purpose of the &if-define; property:


cdl_option CYGDBG_KERNEL_USE_ASSERTS {
    …
    if_define CYGSRC_KERNEL CYGDBG_USE_ASSERTS
    requires  CYGDBG_INFRA_ASSERTION_SUPPORT
}


If this option is active and enabled then the kernel's configuration
header file would end up containing the following:


#ifdef CYGSRC_KERNEL
# define CYGDBG_USE_ASSERTS 1
#endif


Kernel source code can now begin with the following construct:


#define CYGSRC_KERNEL 1
#include <pkgconf/kernel.h>
#include <cyg/infra/cyg_ass.h>


The configuration option only affects kernel source code, assuming
nothing else #define's the symbol
CYGSRC_KERNEL. If the per-package assertion option
is disabled then CYGDBG_USE_ASSERTS will not get
defined. If the option is enabled then
CYGDBG_USE_ASSERTS will get defined and assertions
will be enabled for the kernel sources. It is possible to use the same
mechanism for other facilities such as tracing, and to apply it at a
finer grain such as individual source files by having multiple options
with &if-define; properties and multiple symbols such as
CYGSRC_KERNEL_SCHED_BITMAP_CXX.


The &if-define; property takes two arguments, both of which must be
valid C preprocessor symbols. If the current option is active and
enabled then three lines will be output to the configuration header
file:


#ifdef <symbol1>
# define <symbol2>
#endif


If the option is inactive or disabled then these lines will not be
output. By default the current package's configuration header file
will be used, but it is possible to specify an alternative destination
using a -file option. At present the only
legitimate alternative destination is system.h, the
global configuration header. &if-define; processing happens in
addition to, not instead of, the normal #define
processing or the handling of other header-file related properties.



The infrastructure in the current &eCos; release does not yet work
this way. In future it may do so, and the intention is that suitable
configuration options get generated semi-automatically by the
configuration system rather than having to be defined explicitly.




As an alternative to changing the configuration, updating the build
tree, and so on, it is possible to enable assertions by editing a
source file directly, for example:


#define CYGSRC_KERNEL 1
#define CYGDBG_USE_ASSERTS 1
#include <pkgconf/kernel.h>
#include <cyg/infra/cyg_ass.h>


The assertion header file does not care whether
CYGDBG_USE_ASSERTS is #define'd
via a configuration option or by explicit code. This technique can be
useful to component writers when debugging their source code, although
care has to be taken to remove any such #define's
later on.


 

 
Example

cdl_option CYGDBG_KERNEL_USE_ASSERTS {
    display "Assertions in the kernel package"
    …
    if_define CYGSRC_KERNEL CYGDBG_USE_ASSERTS
    requires  CYGDBG_INFRA_ASSERTION_SUPPORT
}


 
See Also

Properties &define;,
&define-format;,
&define-header;,
&define-proc; and
&no-define;.


 

 


 


&implements;

 

Property &implements;
Enabling this option provides one instance of a more
general interface.

 


cdl_option <name> {
    implements <interface>
    …
}


 
Description

The &CDL; interface concept provides an abstraction mechanism that can
be useful in many different circumstances. Essentially an interface is
a calculated option whose value is the number of active and enabled
options which implement that interface. For example the interface
CYGINT_KERNEL_SCHEDULER has a value corresponding
to the number of schedulers in the system, typically just one.


The &implements; property takes a single argument, which should be the
name of an interface. This interface may be defined in the same
package as the implementor or in some other package. In the latter
case it may sometimes be appropriate for the implementor or the
implementor's package to have a &requires; property for the package
containing the interface. An option may contain multiple &implements;
properties. It is possible for an option to implement a given
interface multiple times, and on occasion this is actually useful.


 
Example

cdl_option CYGSEM_KERNEL_SCHED_MLQUEUE {
    display       "Multi-level queue scheduler"
    default_value 1
    implements    CYGINT_KERNEL_SCHEDULER
    …
}


 
See Also

Command &cdl-interface;.


 

 


 


&include-dir;

 

Property &include-dir;
Specify the desired location of a package's exported
header files in the install tree.

 


cdl_package <name> {
    include_dir <sub-directory>
    …
}


 
Description

Most packages export one or more header files defining their public
interface. For example the C library exports header files such as
stdio.h and
ctype.h.
If the package follows the directory
layout conventions then the exported header files will normally
be found in the package's
include sub-directory.
Alternatively the &include-files; property can be used to specify
which header files should be exported.


By default a package's exported header files will be copied to
the include sub-directory of
the install tree. This is correct for packages like the C library
because that is the correct location for files such as
stdio.h. However to reduce the
probability of name clashes it is desirable for packages to use
different sub-directories, for example infrastructure header files get
copied to include/cyg/infra
rather than to the top-level
include directory itself.


It would be possible to replicate these sub-directories in each
package's source tree, such that the infrastructure header file
sources lived in
include/cyg/infra in the source
tree as well as in the install tree. This would make things more
difficult for the package developers. Instead it is possible to
specify the desired install tree sub-directory using an &include-dir;
property, for example include_dir cyg/infra.


The &include-dir; property can only be used in the body of a
&cdl-package; command, since it applies to all of the header files
exported by a package, and only one &include-dir; property can be
used. If there is no &include-dir; property then exported header files
will end up in the top-level include
directory of the install tree.


 
Example

cdl_package CYGPKG_INFRA {
    display       "Infrastructure"
    include_dir   cyg/infra
    description   "
        Common types and useful macros.
        Tracing and assertion facilities.
        Package startup options."
    …
}


 
See Also

Property &include-files;, and
command &cdl-package;.


 

 


 


&include-files;

 

Property &include-files;
List the header files that are exported by a package.

 


cdl_package <name> {
    include_files <file1> …
    …
}


 
Description

Most packages export one or more header files defining their public
interface. For example the C library exports header files such as
stdio.h and
ctype.h.
If the package follows the directory
layout conventions then the exported header files will normally
be found in the package's
include sub-directory. For
packages which do not follow these conventions, typically simple ones
for which a complicated sub-directory hierarchy is undesirable, there
has to be an alternative way of specifying which header file or files
define the public interface. The &include-files; property provides
support for this.


By default, if a package does not have an
include subdirectory and it
does not have an &include-files; property then all files with a suffix
of .h, .hxx,
.inl or .inc will be treated as
public header files. However some of these may be private files
containing implementation details. If there is an
&include-files; property then only the files listed in that property
will be exported.


If a package should not export any header files but does contain
private implementation headers, an &include-files; property with no
arguments should be used.


 
Example

cdl_package <SOME_PACKAGE> {
    …
    include_dir   <some directory>
    include_files interface.h
}
 
cdl_package <ANOTHER_PACKAGE> {
    …
    include_files
}


 
See Also

Property &include-dir;, and
command &cdl-package;.


 

 


 


&legal-values;

 

Property &legal-values;
Impose constraints on the possible values for an option.

 


cdl_option <name> {
    legal_values <list expression>
    …
}


 
Description

Options with the data or
booldata flavors can have an arbitrary sequence of
characters as their data. In nearly all cases some restrictions have
to be imposed, for example the data should correspond to a number
within a certain range, or it should be one of a small number of
constants. The &legal-values; property can be used to impose such
constraints. The arguments to the property should be a &CDL; list
expression, see  for the
syntactic details. Common examples include:


    legal_values 0 to 0x7fff
    legal_values 9600 19200 38400
    legal_values { "RAM" "ROM" }


The &legal-values; property can only be used for options with the
data or booldata flavors, since
it makes little sense to further constrain the legal values of a
boolean option. An option can have at most one &legal-values;
property.

 


If the first entry in a &legal-values; list expression is a negative
number, for example
legal_values -1 to 1  then this can
be misinterpreted as an option instead of as part of the expression.
Currently the &legal-values; property does not take any options, but
this may change in future. Option processing halts at the sequence
--, so the desired range can be expressed safely
using legal_values -- -1 to 1


 


Architectural HAL packages should provide constants which can be used
in &legal-values; list expressions. For example it should be possible
to specify a numeric range such as
0 to CYGARC_MAXINT, rather than
hard-wiring numbers such as 0x7fffffff which may
not be valid on all targets. Current HAL packages do not define such
constants.


 


The &legal-values; property is restricted mainly to numerical ranges
and simple enumerations, and cannot cope with more complicated data
items. Future versions of the configuration system will provide
additional data validation facilities, for example a
check_proc property which specifies a Tcl script
that can be used to perform the validation.



 
Example

cdl_option CYGNUM_LIBC_TIME_STD_DEFAULT_OFFSET {
    display       "Default Standard Time offset"
    flavor        data
    legal_values  -- -90000 to 90000
    default_value -- 0
    description   "
        This option controls the offset from UTC in
        seconds when in local Standard Time. This
        value can be positive or negative. It
        can also be set at run time using the
        cyg_libc_time_setzoneoffsets() function."
}


 
See Also

Properties &calculated;,
&default-value;, and
&flavor;.


 

 


 


&library;

 

Property &library;
Specify which library should contain the object files
generated by building this package.

 


cdl_package <name> {
    library <library name>
    …
}


 
Description

By default all object files that get built for all packages end up in
a single library, libtarget.a. This makes things
easier for the typical application developer because it is only
necessary to link with a single library, rather than with separate
libraries for each package. It is possible to specify an alternative
library for specific files as an option to the &compile; and
&make-object; properties, and there is one library 
linkend="build">libextras.a which serves a
specific purpose in the build system. The &library; property allows an
alternative library to be specified for all the object files that will
be generated for a given package.


The use of the &library; property should be avoided, since it makes
things more difficult for application developers. The property is
intended only for special cases, for example if there are legal
objections to mingling object files from different packages in a
single library. It could also be used to work around name clash
problems if two packages happen to define an exported symbol with the
same name, but any attempt to use multiple libraries in this way is
error-prone and should be avoided.


The &library; property takes a single argument, the name of a library,
which should follow the standard naming convention of
lib<something>.a. A &library; property can
only occur in the body of a &cdl-package; command and applies to all
object files generated for that package (except where explicitly
overwritten with a -library= option to one of the
build-related properties). A &cdl-package; body can contain at most
one &library; property.


 
Example

cdl_package <SOME_PACKAGE> {
    …
    library  libSomePackage.a
}


 
See Also

Properties &compile;,
&make;, and
&make-object;,
command &cdl-package;.


 

 


 


&make;

 

Property &make;
Define an additional custom build step associated with an
option, resulting in a target that should not go directly into a library.

 


cdl_option <name> {
    make [-priority=<pri>]  {
        <custom build step>
    }
    …
}


 
Description

When building an &eCos; configuration the primary target is a single
library, libtarget.a. In some cases it is
necessary to build some additional targets. For example architectural
HAL packages typically build a linker script and some start-up code.
Such additional targets can be specified by a &make; property. Any
option can have one or more &make; properties, although typically such
properties only occur in the body of a &cdl-package; command.


The &make; property takes a single argument, which resembles a
makefile rule: it consists of a target, a list of dependencies, and
one or more commands that should be executed. However the argument is
not a makefile fragment, and custom build steps may get executed in
build environments that do not involve make. For full details of
custom build steps see .



The exact syntax and limitations of custom build steps have not yet
been finalized, and are subject to change in future versions of the
configuration tools.



The &make; property takes an optional priority argument indicating the
order in which build steps take place. This priority complements the
dependency list, and avoids problems with packages needing to know
details of custom build steps in other packages (which may change
between releases). The defined order is:


 
Priority 0

The header files exported by the current set of packages are copied
to the appropriate places in the
include subdirectory of the
install tree. Any unnecessary copies are avoided, to prevent rebuilds
of package and application source modules caused by header file dependencies.


A possible future enhancement of the build system may result in the
build and install trees being updated automatically if there has been
a change to the ecos.ecc configuration savefile.


 
Priority 100

All files specified in &compile; properties will get built, producing
the corresponding object files. In addition any custom build steps
defined by &make-object; properties get executed, unless there is
a -priority= option.


 
Priority 200

The libraries now get built using the appropriate object files.


 
Priority 300

Any custom build steps specified by &make; properties now get
executed, unless the priority for a particular build step is changed
from its default.



 

For example, if a custom build step needs to take place before any of
the normal source files get compiled then it should be given a
priority somewhere between 0 and 100. If a custom build step involves
post-processing an object file prior to its incorporation into a
library then a priority between 100 and 200 should be used.

 

 
Example

cdl_package CYGPKG_HAL_MN10300_AM33 {
    display       "MN10300 AM33 variant"
    parent        CYGPKG_HAL_MN10300
    implements    CYGINT_HAL_MN10300_VARIANT
    hardware
    include_dir   cyg/hal
    define_header hal_mn10300_am33.h
    description   "
           The MN10300 AM33 variant HAL package provides generic
           support for this processor architecture. It is also
           necessary to select a specific target platform HAL
           package."
 
    make {
        <PREFIX>/lib/target.ld: <PACKAGE>/src/mn10300_am33.ld
        $(CC) -E -P -Wp,-MD,target.tmp -DEXTRAS=1 -xc $(INCLUDE_PATH) $(CFLAGS) -o $@ $<
        @echo $@ ": \\" > $(notdir $@).deps
        @tail +2 target.tmp >> $(notdir $@).deps
        @echo >> $(notdir $@).deps
        @rm target.tmp
    }
}


 
See Also

Properties compile,
make_object and
library.


 

 


 


&make-object;

 

Property &make-object;
Define a custom build step, resulting in an object file
that should go into a library.

 


cdl_option <name> {
    make_object [-library=<library>] [-priority=<pri>]  {
        <custom build step>
    }
    …
}


 
Description

When building an &eCos; configuration the primary target is a single
library, libtarget.a. Most of the object files
which go into this library will be generated as a result of &compile;
properties. Occasionally it may be necessary to have special build
steps for a given object file, and this can be achieved with a
&make-object; property. The use of this property should be avoided
whenever possible because it greatly increases the risk of portability
problems, both on the host side because of possible problems with the
tools, and on the target side because a custom build step may not
allow adequately for the wide variety of architectures supported by
&eCos;.


The &make-object; property takes a single argument, which resembles a
makefile rule: it consists of a target, a list of dependencies, and
one or more commands that should be executed. The target should be an
object file. However the &make-object; argument is not a makefile
fragment, and custom build steps may get executed in build
environments that do not involve make. For full details of custom
build steps see .



The exact syntax and limitations of custom build steps have not yet
been finalized, and may change in future versions of the
configuration tools.



The &make-object; property takes an optional library argument. If no
library is specified then the default library for the current package
will be used, which will be libtarget.a unless
the &cdl-package; command contains a &library; property.


The &make-object; property also takes an optional priority argument
indicating the order in which build steps take place. This priority
complements the dependency list, and avoids problems with packages
needing to know details of custom build steps in other packages (which
may change between releases). The defined order is:


 
Priority 0

The header files exported by the current set of packages are copied
to the appropriate places in the
include subdirectory of the
install tree. Any unnecessary copies are avoided, to prevent rebuilds
of package and application source modules caused by header file dependencies.


A possible future enhancement of the build system may result in the
build and install trees being updated automatically if there has been
a change to the ecos.ecc configuration savefile.


 
Priority 100

All files specified in &compile; properties will get built, producing
the corresponding object files. In addition any custom build steps
defined by &make-object; properties get executed, unless there is a
-priority= option.


 
Priority 200

The libraries now get built using the appropriate object files.


 
Priority 300

Any custom build steps specified by &make; properties now get
executed, unless the priority for a particular build step is changed
from its default.



 

For example, if a custom build step needs to take place before any of
the normal source files get compiled then it should be given a
priority somewhere between 0 and 100. If a custom build step involves
post-processing an object file prior to its incorporation into a
library then a priority between 100 and 200 should be used. It is not
sensible to have a priority above 200, since that would imply building
an additional object file for a library that has already been created.


 
Example

cdl_option XXX {
    …
    make_object {
        parser.o: parser.y
                yacc $<
                $(CC) $(CFLAGS) -o $@ y.tab.c
    }
}


 
See Also

Properties compile,
make and
library.


 

 


 


&no-define;

 

Property &no-define;
Suppress the normal generation of a preprocessor
#define symbol in a configuration header file.

 


cdl_option <name> {
    no_define
    …
}


 
Description

By default all active and enabled properties result in either one or
two #define'd symbols in the package's
configuration header file, and this is one of the main ways in which
options can affect packages at build-time. It is possible to suppress
the default #define's by specifying a
&no-define; property in the body of an option or other &CDL; entity.
This property takes no arguments and should occur only once in a given
body.


The &no-define; property is frequently used in conjunction with one of
the other header-file related properties such as &define;. If one of
the other properties is used to export the required information to a
configuration header file then often there is little point in
exporting the default #define as
well &mdash  in fact there could be a name clash. The
&no-define; property can also be useful if the sole purpose of an
option is to affect which files get built, and the default
#define would never get tested in any source code.
However in such cases the default #define is
mostly harmless and there is little to be gained by suppressing it.

 

 
Example

cdl_component CYG_HAL_STARTUP {
    display       "Startup type"
    flavor        data
    legal_values  { "RAM" "ROM" }
    default_value {"RAM"}
    no_define
    define -file system.h CYG_HAL_STARTUP
    …
}


 
See Also

Properties &define;,
&define-format;,
&define-header;,
&define-proc; and
&if-define;.


 

 


 


&parent;

 

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

 


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.


As a special case, if an empty string is specified for the parent then
the option is placed at the top of the hierarchy, ahead of any
packages which are not explicitly re-parented in this way. This
facility is useful for configuration options such as global
preferences and default compiler flags.

 


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.


 

 
Example

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


 
See Also

Property &script;,
commands &cdl-component; and
&cdl-package;.


 

 


 


&requires;

 

Property &requires;
List constraints that the configuration should satisfy if
a given option is active and enabled..

 


cdl_option <name> {
    requires <goal expression>
    …
}


 
Description

Configuration options are not independent. For example the C library
can provide thread-safe implementations of certain functions, but only
if the kernel is present, if the kernel provides multi-threading, and
if the kernel options related to per-thread data are enabled. It is
possible to express such constraints using &requires; properties.


The arguments to a &requires; property should constitute a goal
expression, as described in .
Most goal expressions are relatively simple because the constraints
being described are simple, but complicated expressions can be used
when necessary. The body of an option or other CDL entity can contain
any number of &requires; constraints. If the option is active and
enabled then all these constraints should be satisfied, and any goal
expressions which evaluate to 0 will result in
conflicts being raised. It is possible for users to ignore such
conflicts and attempt to build the current configuration anyway, but
there is no guarantee that anything will work. If an option is
inactive or disabled then its &requires; constraints will be ignored.


The configuration system contains an inference engine which can
resolve many types of conflicts automatically. For example, if option
A is enabled and requires an option
B that is currently disabled then the inference
engine may attempt to resolve the conflict by enabling
B. However this will not always be possible, for
example there may be other constraints in the configuration which
force B to be disabled at present, in which case
user intervention is required.


 
Example

cdl_component CYGPKG_IO_SERIAL_POWERPC_COGENT_SERIAL_A {
    display       "Cogent PowerPC serial port A driver"
    flavor        bool
    default_value 0
    requires      (CYGIMP_KERNEL_INTERRUPTS_CHAIN || \
                   !CYGPKG_IO_SERIAL_POWERPC_COGENT_SERIAL_B)
    …
}


 
See Also

Property &active-if;.


 

 


 


&script;

 

Property &script;
Include additional configuration information from another
CDL script.

 


cdl_component <name> {
    script <filename>
    …
}


 
Description

It is possible to define all the configuration options and
sub-components for a given package in a single CDL script, either by
nesting them in the appropriate command bodies, by extensive use of
the &parent; property, or by some combination of these two. However
for large packages this is inconvenient and it is better to split the
raw configuration data over several different files. The &script;
property can be used to achieve this. It takes a single filename as
argument. If the package follows the 
linkend="package.hierarchy">directory layout conventions then
the configuration tools will look for the specified file in the
cdl sub-directory of the
package, otherwise it will look for the file relative to the package's
top-level directory.


The &script; property can only occur in the body of a &cdl-component
command, and only one &script; property per body is allowed.


 
Example

cdl_component CYGPKG_UITRON_TASKS {
    display      "Tasks"
    flavor        none
    description   "
        uITRON Tasks are the basic blocks of multi-tasking
        in the uITRON world; they are threads or lightweight
        processes, sharing the address space and the CPU.
        They communicate using the primitives outlined above.
        Each has a stack, an entry point (a C or C++ function),
        and (where appropriate) a scheduling priority."
 
    script        tasks.cdl
}


 
See Also

Command  &cdl-component;,
and property &parent;.


 

 

 

Browse

Tools

Subversion Repositories openrisc

[/] [openrisc/] [trunk/] [rtos/] [ecos-3.0/] [host/] [libcdl/] [doc/] [reference.sgml] - Blame information for rev 790
