URL
https://opencores.org/ocsvn/openrisc/openrisc/trunk
Subversion Repositories openrisc
[/] [openrisc/] [trunk/] [rtos/] [ecos-2.0/] [doc/] [html/] [cdl-guide/] [language.html] - Rev 565
Go to most recent revision | Compare with Previous | Blame | View Log
<!-- Copyright (C) 2003 Red Hat, Inc. -->
<!-- This material may be distributed only subject to the terms -->
<!-- and conditions set forth in the Open Publication License, v1.0 -->
<!-- or later (the latest version is presently available at -->
<!-- http://www.opencontent.org/openpub/). -->
<!-- Distribution of the work or derivative of the work in any -->
<!-- standard (paper) book form is prohibited unless prior -->
<!-- permission is obtained from the copyright holder. -->
<HTML
><HEAD
><TITLE
>The CDL Language</TITLE
><meta name="MSSmartTagsPreventParsing" content="TRUE">
<META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
"><LINK
REL="HOME"
TITLE="The eCos Component Writer's Guide"
HREF="cdl-guide.html"><LINK
REL="PREVIOUS"
TITLE="Making a Package Distribution"
HREF="package.distrib.html"><LINK
REL="NEXT"
TITLE="CDL Commands"
HREF="language.commands.html"></HEAD
><BODY
CLASS="CHAPTER"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>The <SPAN
CLASS="APPLICATION"
>eCos</SPAN
> Component Writer's Guide</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="package.distrib.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="language.commands.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="CHAPTER"
><H1
><A
NAME="LANGUAGE">Chapter 3. The CDL Language</H1
><DIV
CLASS="TOC"
><DL
><DT
><B
>Table of Contents</B
></DT
><DT
><A
HREF="language.html#LANGUAGE.OVERVIEW"
>Language Overview</A
></DT
><DT
><A
HREF="language.commands.html"
>CDL Commands</A
></DT
><DT
><A
HREF="language.properties.html"
>CDL Properties</A
></DT
><DT
><A
HREF="language.naming.html"
>Option Naming Convention</A
></DT
><DT
><A
HREF="language.tcl.html"
>An Introduction to Tcl</A
></DT
><DT
><A
HREF="language.values.html"
>Values and Expressions</A
></DT
><DT
><A
HREF="language.interface.html"
>Interfaces</A
></DT
><DT
><A
HREF="language.database.html"
>Updating the <SPAN
CLASS="DATABASE"
>ecos.db</SPAN
> database</A
></DT
></DL
></DIV
><P
>The <SPAN
CLASS="APPLICATION"
>CDL</SPAN
> language is a key part of the <SPAN
CLASS="APPLICATION"
>eCos</SPAN
> component framework.
All packages must come with at least one <SPAN
CLASS="APPLICATION"
>CDL</SPAN
> script, to describe
that package to the framework. The information in that script includes
details of all the configuration options and how to build the package.
Implementing a new component or turning some existing code into an
<SPAN
CLASS="APPLICATION"
>eCos</SPAN
> component always involves writing corresponding <SPAN
CLASS="APPLICATION"
>CDL</SPAN
>. This
chapter provides a description of the <SPAN
CLASS="APPLICATION"
>CDL</SPAN
> language. Detailed
information on specific parts of the language can be found in <A
HREF="reference.html"
>Chapter 5</A
>.</P
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="LANGUAGE.OVERVIEW">Language Overview</H1
><P
>A very simple <SPAN
CLASS="APPLICATION"
>CDL</SPAN
> script would look like this:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>cdl_package CYGPKG_ERROR {
display "Common error code support"
compile strerror.cxx
include_dir cyg/error
description "
This package contains the common list of error and
status codes. It is held centrally to allow
packages to interchange error codes and status
codes in a common way, rather than each package
having its own conventions for error/status
reporting. The error codes are modelled on the
POSIX style naming e.g. EINVAL etc. This package
also provides the standard strerror() function to
convert error codes to textual representation."
}</PRE
></TD
></TR
></TABLE
><P
>This describes a single package, the error code package, which does
not have any sub-components or configuration options. The package has
an internal name, <TT
CLASS="VARNAME"
>CYGPKG_ERROR</TT
>, which can be
referenced in other <SPAN
CLASS="APPLICATION"
>CDL</SPAN
> scripts using e.g.
<TT
CLASS="LITERAL"
>requires CYGPKG_ERROR</TT
>. There will also be a
<TT
CLASS="LITERAL"
>#define</TT
> for this symbol in a configuration header
file. In addition to the package name, this script provides a number
of properties for the package as a whole. The <SPAN
CLASS="PROPERTY"
>display</SPAN
> property
provides a short description. The <SPAN
CLASS="PROPERTY"
>description</SPAN
> property involves a
rather longer one, for when users need a bit more information. The
<SPAN
CLASS="PROPERTY"
>compile</SPAN
> and <SPAN
CLASS="PROPERTY"
>include_dir</SPAN
> properties list the consequences of this
package at build-time. The package appears to lack any on-line
documentation. </P
><P
>Packages could be even simpler than this. If the package only provides
an interface and there are no files to be compiled then there is no
need for a <SPAN
CLASS="PROPERTY"
>compile</SPAN
> property. Alternatively if there are no exported
header files, or if the exported header files should go to the
top-level of the <TT
CLASS="FILENAME"
>install/include</TT
> directory, then there is
no need for an <SPAN
CLASS="PROPERTY"
>include_dir</SPAN
> property. Strictly speaking the
<SPAN
CLASS="PROPERTY"
>description</SPAN
> and <SPAN
CLASS="PROPERTY"
>display</SPAN
> properties are optional as well, although
application developers would not appreciate the resulting lack of
information about what the package is supposed to do.</P
><P
>However many packages tend to be a bit more complicated than the error
package, containing various sub-components and configuration options.
These are also defined in the <SPAN
CLASS="APPLICATION"
>CDL</SPAN
> scripts and in much the same way
as the package. For example, the following excerpt comes from the
infrastructure package:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>cdl_component CYGDBG_INFRA_DEBUG_TRACE_ASSERT_BUFFER {
display "Buffered tracing"
default_value 1
active_if CYGDBG_USE_TRACING
description "
An output module which buffers output from tracing and
assertion events. The stored messages are output when an
assert fires, or CYG_TRACE_PRINT() (defined in
<cyg/infra/cyg_trac.h>) is called. Of course, there will
only be stored messages if tracing per se (CYGDBG_USE_TRACING)
is enabled above."
cdl_option CYGDBG_INFRA_DEBUG_TRACE_BUFFER_SIZE {
display "Trace buffer size"
flavor data
default_value 32
legal_values 5 to 65535
description "
The size of the trace buffer. This counts the number of
trace records stored. When the buffer fills it either
wraps, stops recording, or generates output."
}
…
}</PRE
></TD
></TR
></TABLE
><P
>Like a <TT
CLASS="LITERAL"
>cdl_package</TT
>, a <TT
CLASS="LITERAL"
>cdl_component</TT
> has a name and a body. The
body contains various properties for that component, and may also
contain sub-components or options. Similarly a <TT
CLASS="LITERAL"
>cdl_option</TT
> has a
name and a body of properties. This example lists a number of
new properties: <SPAN
CLASS="PROPERTY"
>default_value</SPAN
>, <SPAN
CLASS="PROPERTY"
>active_if</SPAN
>, <SPAN
CLASS="PROPERTY"
>flavor</SPAN
> and
<SPAN
CLASS="PROPERTY"
>legal_values</SPAN
>. The meaning of most of these should be fairly obvious.
The next sections describe the various <SPAN
CLASS="APPLICATION"
>CDL</SPAN
> commands and properties. </P
><P
>There is one additional and very important point: <SPAN
CLASS="APPLICATION"
>CDL</SPAN
> is not a
completely new language; instead it is implemented as an extension of
the existing <SPAN
CLASS="APPLICATION"
>Tcl</SPAN
> scripting language. The syntax of a <SPAN
CLASS="APPLICATION"
>CDL</SPAN
> script is
<SPAN
CLASS="APPLICATION"
>Tcl</SPAN
> syntax, which is described below. In addition some of the more
advanced facilities of <SPAN
CLASS="APPLICATION"
>CDL</SPAN
> involve embedded fragments of <SPAN
CLASS="APPLICATION"
>Tcl</SPAN
> code,
for example there is a <SPAN
CLASS="PROPERTY"
>define_proc</SPAN
> property which specifies some
code that needs to be executed when the component framework generates
the configuration header files.</P
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="package.distrib.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="cdl-guide.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="language.commands.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Making a Package Distribution</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
> </TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>CDL Commands</TD
></TR
></TABLE
></DIV
></BODY
></HTML
> Go to most recent revision | Compare with Previous | Blame | View Log