?? language.properties.html
字號:
<!-- 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
>CDL Properties</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="UP"
TITLE="The CDL Language"
HREF="language.html"><LINK
REL="PREVIOUS"
TITLE="CDL Commands"
HREF="language.commands.html"><LINK
REL="NEXT"
TITLE="Option Naming Convention"
HREF="language.naming.html"></HEAD
><BODY
CLASS="SECT1"
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="language.commands.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Chapter 3. The CDL Language</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="language.naming.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="LANGUAGE.PROPERTIES">CDL Properties</H1
><P
>Each package, component, option, and interface has a body of
properties, which provide the component framework with information
about how to handle each option. For example there is a property for a
descriptive text message which can be displayed to a user who is
trying to figure out just what effect manipulating the option would
have on the target application. There is another property for the
default value, for example whether a particular option should be
enabled or disabled by default.</P
><P
>All of the properties are optional, it is legal to define a
configuration option which has an empty body. However some properties
are more optional than others: users will not appreciate having to
manipulate an option if they are not given any sort of description or
documentation. Other properties are intended only for very specific
purposes, for example <SPAN
CLASS="PROPERTY"
>make_object</SPAN
> and <SPAN
CLASS="PROPERTY"
>include_files</SPAN
>, and are used
only rarely.</P
><P
>Because different properties serve very different purposes, their
syntax is not as uniform as the top-level commands. Some properties
take no arguments at all. Other properties take a single argument such
as a description string, or a list of arguments such as a <SPAN
CLASS="PROPERTY"
>compile</SPAN
>
property which specifies the file or files that should be compiled if
a given option is active and enabled. The <SPAN
CLASS="PROPERTY"
>define_proc</SPAN
> property takes
as argument a snippet of <SPAN
CLASS="APPLICATION"
>Tcl</SPAN
> code. The <SPAN
CLASS="PROPERTY"
>active_if</SPAN
>, <SPAN
CLASS="PROPERTY"
>calculated</SPAN
>,
<SPAN
CLASS="PROPERTY"
>default_value</SPAN
>, <SPAN
CLASS="PROPERTY"
>legal_values</SPAN
> and <SPAN
CLASS="PROPERTY"
>requires</SPAN
> properties take various
expressions. Additional properties may be defined in future which take
new kinds of arguments.</P
><P
>All property parsing code supports options for every property,
although at present the majority of properties do not yet take any
options. Any initial arguments that begin with a hyphen character
<TT
CLASS="LITERAL"
>-</TT
> will be interpreted as an option, for example:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>cdl_package CYGPKG_HAL_ARM {
…
make -priority 1 {
…
}
}</PRE
></TD
></TR
></TABLE
><P
>If the option involves additional data, as for the
<TT
CLASS="LITERAL"
>-priority</TT
> example above, then this can be written
as either <TT
CLASS="LITERAL"
>-priority=1</TT
> or as
<TT
CLASS="LITERAL"
>-priority 1</TT
>. On occasion the option parsing
code can get in the way, for example:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>cdl_option CYGNUM_LIBC_TIME_DST_DEFAULT_STATE {
…
legal_values -1 to 1
default_value -1
}</PRE
></TD
></TR
></TABLE
><P
>Neither the <SPAN
CLASS="PROPERTY"
>legal_values</SPAN
> nor the <SPAN
CLASS="PROPERTY"
>default_value</SPAN
> property will
accept <TT
CLASS="LITERAL"
>-1</TT
> as a valid option, so this will result in
syntax errors when the <SPAN
CLASS="APPLICATION"
>CDL</SPAN
> script is read in by the component
framework. To avoid problems, the option parsing code will recognize
the string <TT
CLASS="LITERAL"
>--</TT
> and will not attempt to interpret any
subsequent arguments. Hence this option should be written as:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>cdl_option CYGNUM_LIBC_TIME_DST_DEFAULT_STATE {
…
legal_values -- -1 to 1
default_value -- -1
}</PRE
></TD
></TR
></TABLE
><P
>The property parsing code involves a recursive invocation of the Tcl
interpreter that is used to parse the top-level commands. This means
that some characters in the body of an option will be treated
specially. The <TT
CLASS="LITERAL"
>#</TT
> character can be used for
comments. The backslash character <TT
CLASS="LITERAL"
>\</TT
>, the
dollar character <TT
CLASS="LITERAL"
>$</TT
>, square brackets
<TT
CLASS="LITERAL"
>[</TT
> and <TT
CLASS="LITERAL"
>]</TT
>, braces
<TT
CLASS="LITERAL"
>{</TT
> and <TT
CLASS="LITERAL"
>}</TT
>, and the quote character
<TT
CLASS="LITERAL"
>"</TT
> may all receive special treatment. Most of the
time this is not a problem because these characters are not useful for
most properties. On occasion having a <SPAN
CLASS="APPLICATION"
>Tcl</SPAN
> interpreter around
performing the parser can be very powerful. For more details of
how the presence of a <SPAN
CLASS="APPLICATION"
>Tcl</SPAN
> interpreter can affect <SPAN
CLASS="APPLICATION"
>CDL</SPAN
> scripts,
see <A
HREF="language.tcl.html"
>the Section called <I
>An Introduction to Tcl</I
></A
>.</P
><P
>Many of the properties can be used in any of <TT
CLASS="LITERAL"
>cdl_package</TT
>,
<TT
CLASS="LITERAL"
>cdl_component</TT
>, <TT
CLASS="LITERAL"
>cdl_option</TT
> or <TT
CLASS="LITERAL"
>cdl_interface</TT
>. Other properties are
more specific. The <SPAN
CLASS="PROPERTY"
>script</SPAN
> property is only relevant to components.
The <SPAN
CLASS="PROPERTY"
>define_header</SPAN
>, <SPAN
CLASS="PROPERTY"
>hardware</SPAN
>, <SPAN
CLASS="PROPERTY"
>include_dir</SPAN
>, <SPAN
CLASS="PROPERTY"
>include_files</SPAN
>, and
<SPAN
CLASS="PROPERTY"
>library</SPAN
> properties apply to a package as a whole, so can only occur
in the body of a <TT
CLASS="LITERAL"
>cdl_package</TT
> command. The <SPAN
CLASS="PROPERTY"
>calculated</SPAN
>,
<SPAN
CLASS="PROPERTY"
>default_value</SPAN
>, <SPAN
CLASS="PROPERTY"
>legal_values</SPAN
> and <SPAN
CLASS="PROPERTY"
>flavor</SPAN
> properties are not
relevant to packages, as will be explained later. The <SPAN
CLASS="PROPERTY"
>calculated</SPAN
> and
<SPAN
CLASS="PROPERTY"
>default_value</SPAN
> properties are also not relevant to interfaces.</P
><P
>This section lists the various properties, grouped by purpose. Each
property also has a full reference page in <A
HREF="reference.html"
>Chapter 5</A
>.
Properties related to values and expressions are described in more
detail in <A
HREF="language.values.html"
>the Section called <I
>Values and Expressions</I
></A
>. Properties related to
header file generation and to the build process are described in
<A
HREF="build.html"
>Chapter 4</A
>.</P
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="LANGUAGE.PROPERTIES.USER">Information-providing Properties</H2
><P
>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 <A
HREF="ref.display.html"
><SPAN
CLASS="PROPERTY"
>display</SPAN
></A
> property gives
a textual alias for an option, which is usually more comprehensible
than something like <TT
CLASS="LITERAL"
>CYGPKG_LIBC_TIME_ZONES`</TT
>; the
<A
HREF="ref.description.html"
><SPAN
CLASS="PROPERTY"
>description</SPAN
></A
> property gives a
longer description, typically a paragraph or so; the <A
HREF="ref.doc.html"
><SPAN
CLASS="PROPERTY"
>doc</SPAN
></A
> property specifies the location of
additional on-line documentation related to a configuration option. In
the context of a graphical tool the <SPAN
CLASS="PROPERTY"
>display</SPAN
> string will be the
primary way for users to identify configuration options; the
<SPAN
CLASS="PROPERTY"
>description</SPAN
> paragraph will be visible whenever the option is
selected; the on-line documentation will only be accessed when the
user explicitly requests it.</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>cdl_package CYGPKG_UITRON {
display "uITRON compatibility layer"
doc ref/ecos-ref.a.html
description "
eCos supports a uITRON Compatibility Layer, providing
full Level S (Standard) compliance with Version 3.02 of
the uITRON Standard, plus many Level E (Extended) features.
uITRON is the premier Japanese embedded RTOS standard."
…
}</PRE
></TD
></TR
></TABLE
><P
>All three properties take a single argument. For <SPAN
CLASS="PROPERTY"
>display</SPAN
> and
<SPAN
CLASS="PROPERTY"
>description</SPAN
> this argument is just a string. For <SPAN
CLASS="PROPERTY"
>doc</SPAN
> it should be a
pointer to a suitable HTML file, optionally including an anchor within
that page. If the <A
HREF="package.html#PACKAGE.HIERARCHY"
>directory layout
conventions</A
> are observed then the component framework will look
for the HTML file in the package's <TT
CLASS="FILENAME"
>doc</TT
> sub-directory, otherwise the <SPAN
CLASS="PROPERTY"
>doc</SPAN
>
filename will be treated as relative to the package's top-level directory.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="LANGUAGE.PROPERTIES.HIERARCHY">The Configuration Hierarchy</H2
><P
>There are two properties related to the hierarchical organization of
components and options: <A
HREF="ref.parent.html"
><SPAN
CLASS="PROPERTY"
>parent</SPAN
></A
> and
<A
HREF="ref.script.html"
><SPAN
CLASS="PROPERTY"
>script</SPAN
></A
>.</P
><P
>The <SPAN
CLASS="PROPERTY"
>parent</SPAN
> property can be used to move a <SPAN
CLASS="APPLICATION"
>CDL</SPAN
> entity somewhere
else in the hierarchy. The most common use is for packages, to avoid
having all the packages appear at the top-level of the configuration
hierarchy. For example an architectural HAL package such as
<TT
CLASS="VARNAME"
>CYGPKG_HAL_SH</TT
> is placed below the common HAL
package <TT
CLASS="VARNAME"
>CYGPKG_HAL</TT
> using a <SPAN
CLASS="PROPERTY"
>parent</SPAN
> property.</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>cdl_package CYGPKG_HAL_SH {
display "SH architecture"
parent CYGPKG_HAL
…
}</PRE
></TD
></TR
></TABLE
><P
>The <SPAN
CLASS="PROPERTY"
>parent</SPAN
> property can also be used in the body of a
<TT
CLASS="LITERAL"
>cdl_component</TT
>, <TT
CLASS="LITERAL"
>cdl_option</TT
> or <TT
CLASS="LITERAL"
>cdl_interface</TT
>, but this is less
common. However care has to be taken since excessive re-parenting can
be confusing. Care also has to be taken when reparenting below some
other package that may not actually be loaded in a given
configuration, since the resulting behavior is undefined.</P
><P
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -