📄 language.values.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
>Values and Expressions</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="An Introduction to Tcl"
HREF="language.tcl.html"><LINK
REL="NEXT"
TITLE="Interfaces"
HREF="language.interface.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.tcl.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.interface.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="LANGUAGE.VALUES">Values and Expressions</H1
><P
>It is fairly reasonable to expect that enabling or disabling a
configuration option such as
<TT
CLASS="VARNAME"
>CYGVAR_KERNEL_THREADS_DATA</TT
> in some way affects its
<SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>value</I
></SPAN
>. This will have an effect on any
expressions that reference this option such as
<TT
CLASS="LITERAL"
>requires CYGVAR_KERNEL_THREADS_DATA</TT
>. It will
also affect the consequences of that option: how it affects the build
process and what happens to any constraints that
<TT
CLASS="VARNAME"
>CYGVAR_KERNEL_THREADS_DATA</TT
> may impose (as opposed
to constraints on this option imposed by others).</P
><P
>In a language like C the handling of variables is relatively
straightforward. If a variable <TT
CLASS="VARNAME"
>x</TT
> gets referenced in
an expression such as <TT
CLASS="LITERAL"
>if (x != 0)</TT
>,
and that variable is not defined anywhere, then the code will fail to
build, typically with an unresolved error at link-time. Also in C
a variable <TT
CLASS="VARNAME"
>x</TT
> does not live in any hierarchy, so its
value for the purposes of expression evaluation is not affected by
anything else. C variables also have a clear type such as
<TT
CLASS="LITERAL"
>int</TT
> or <TT
CLASS="LITERAL"
>long double</TT
>. </P
><P
>In <SPAN
CLASS="APPLICATION"
>CDL</SPAN
> things are not so straightforward.</P
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="LANGUAGE.VALUES.VALUE">Option Values</H2
><P
>There are four factors which go into an option's value:</P
><P
></P
><OL
TYPE="1"
><LI
><P
>An option may or may not be loaded.</P
></LI
><LI
><P
>If the option is loaded, it may or may not be active.</P
></LI
><LI
><P
>Even if the option is active, it may or may not be enabled.</P
></LI
><LI
><P
>If the option is loaded, active and enabled then it will have some
associated data which constitutes its value.</P
></LI
></OL
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="LANGUAGE.VALUES.VALUE.LOADED">Is the Option Loaded?</H3
><P
>At any one time a configuration will contain only a subset of all
possible packages. In fact it is impossible to combine certain
packages in a single configuration. For example architectural HAL
packages should contain a set of options defining endianness, the
sizes of basic data types and so on (many of which will of course be
constant for any given architecture). Any attempt to load two
architectural HAL packages into a configuration will fail because of
the resulting name clash. Since <SPAN
CLASS="APPLICATION"
>CDL</SPAN
> expressions can reference
options in other packages, and often need to do so, it is essential to
define the resulting behavior.</P
><P
>One complication is that the component framework does not know about
every single option in every single package. Obviously it cannot know
about packages from arbitrary third parties which have not been
installed. Even for packages which have been installed, the current
repository database does not hold details of every option, only of the
packages themselves. If a <SPAN
CLASS="APPLICATION"
>CDL</SPAN
> expression contains a reference to
some option <TT
CLASS="VARNAME"
>CYGSEM_KERNEL_SCHED_TIMESLICE</TT
> then the
component framework will only know about this option if the kernel
package is actually loaded into the current configuration. If the
package is not loaded then theoretically the framework might guess
that the option is somehow related to the kernel by examining the
option name but this would not be robust: the option could easily be
part of some other package that violates the naming convention.</P
><P
>Assume that the user is building a minimal configuration which does
not contain the kernel package, but does have other packages which
contain the following constraints:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
> requires CYGPKG_KERNEL
requires CYGPKG_KERNEL_THREADS_DATA
requires !CYGSEM_KERNEL_SCHED_TIMESLICE</PRE
></TD
></TR
></TABLE
><P
>Clearly the first constraint is not satisfied because the kernel is
not loaded. The second constraint is also not satisfied. The third
constraint is trivially satisfied: if there is no kernel then the
kernel's timeslicing support cannot possibly be enabled. </P
><P
>Any options which are not in the current configuration are handled as
follows: </P
><P
></P
><OL
TYPE="1"
><LI
><P
>Any references to that option will evaluate to <TT
CLASS="LITERAL"
>0</TT
>,
so <TT
CLASS="LITERAL"
>requires !CYGSEM_KERNEL_SCHED_TIMESLICE</TT
> will
be satisfied but
<TT
CLASS="LITERAL"
>requires CYGSEM_KERNEL_THREADS_DATA</TT
> will not
be satisfied.</P
></LI
><LI
><P
>An option that is not loaded has no consequences on the build process.
It cannot directly result in any <TT
CLASS="LITERAL"
>#define's</TT
> in a
configuration header file, nor in any files being compiled. This is
only reasonable: if the option is not loaded then the component
framework has no way of knowing about any <SPAN
CLASS="PROPERTY"
>compile</SPAN
> or similar
properties. An option that is not loaded can have indirect
consequences by being referenced in <SPAN
CLASS="APPLICATION"
>CDL</SPAN
> expressions.</P
></LI
><LI
><P
>An option that is not loaded cannot impose any constraints on the rest
of the configuration. Again this is the only reasonable behavior: if
the option is not loaded then any associated <SPAN
CLASS="PROPERTY"
>requires</SPAN
> or
<SPAN
CLASS="PROPERTY"
>legal_values</SPAN
> properties will not be known.</P
></LI
></OL
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="LANGUAGE.VALUES.VALUE.ACTIVE">Is the Option Active</H3
><P
>The next issue to consider is whether or not a particular option is
active. Configuration options are organized in a hierarchy of
components and sub-components. For example the C library package
contains a component <TT
CLASS="VARNAME"
>CYGPKG_LIBC_STDIO</TT
> containing
all the options related to standard I/O. If a user disables the
component as a whole then all the options below it become inactive: it
makes no sense to disable all stdio functionality and then manipulate
the buffer sizes.</P
><P
>Inactive is not quite the same as disabled, although the effects are
similar. The value of an inactive option is preserved. If the user
modifies a buffer size option, then disables the whole stdio
component, the buffer size value remains in case the stdio component
is re-enabled later on. Some tools such as the graphical configuration
tool will treat inactive options specially, for example such options
may be grayed out.</P
><P
>The active or inactive state of an option may affect other packages.
For example a package may use the <TT
CLASS="FUNCTION"
>sprintf</TT
>
function and require support for floating point conversions, a
constraint that is not satisfied if the relevant option is inactive.
It is necessary to define exactly what it means for an option to be
inactive:</P
><P
></P
><OL
TYPE="1"
><LI
><P
>An option is inactive if its parent is either inactive or disabled.
For example if <TT
CLASS="VARNAME"
>CYGPKG_LIBC_STDIO</TT
> is disabled then
all the options and sub-components become inactive; since
<TT
CLASS="VARNAME"
>CYGPKG_LIBC_STDIO_FLOATING_POINT</TT
> is now inactive,
<TT
CLASS="VARNAME"
>CYGSEM_LIBC_STDIO_PRINTF_FLOATING_POINT</TT
> is inactive
as well.</P
></LI
><LI
><P
>Options may also be inactive as a result of an <SPAN
CLASS="PROPERTY"
>active_if</SPAN
> property.
This is useful if a particular option is only relevant if two or more
disjoint sets of conditions need to be satisfied, since the
hierarchical structure can only cope with at most one such set.</P
></LI
><LI
><P
>If an option is inactive then any references to that option in <SPAN
CLASS="APPLICATION"
>CDL</SPAN
>
expressions will evaluate to <TT
CLASS="LITERAL"
>0</TT
>. Hence a constraint
of the form
<TT
CLASS="LITERAL"
>requires CYGSEM_LIBC_STDIO_PRINTF_FLOATING_POINT</TT
>
is not satisfied if the entire stdio component is disabled.</P
></LI
><LI
><P
>An option that is inactive has no consequences on the build process.
No <TT
CLASS="LITERAL"
>#define</TT
> will be generated. Any <SPAN
CLASS="PROPERTY"
>compile</SPAN
> or
similar properties will be ignored.</P
></LI
><LI
><P
>An option that is inactive cannot impose any constraints on the rest
of the configuration. For example
<TT
CLASS="VARNAME"
>CYGSEM_LIBC_STDIO_PRINTF_FLOATING_POINT</TT
> has a
dependency <TT
CLASS="LITERAL"
>requires CYGPKG_LIBM</TT
>, but if all of
the stdio functionality is disabled then this constraint is ignored
(although of course there may be other packages which have a
dependency on <TT
CLASS="VARNAME"
>CYGPKG_LIBM</TT
>.</P
></LI
></OL
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="LANGUAGE.VALUES.VALUE.ENABLED">Is the Option Enabled? What is the Data?</H3
><P
>The majority of configuration options are boolean in nature, so the
user can either enable or disable some functionality. Some options are
different. For example <TT
CLASS="VARNAME"
>CYGNUM_LIBC_STDIO_BUFSIZE</TT
> is
a number, and <TT
CLASS="VARNAME"
>CYGDAT_LIBC_STDIO_DEFAULT_CONSOLE</TT
> is
a string corresponding to a device name. A few options like
<TT
CLASS="VARNAME"
>CYGDAT_UITRON_TASK_EXTERNS</TT
> can get very
complicated. <SPAN
CLASS="APPLICATION"
>CDL</SPAN
> has to cope with this variety, and define the exact
behavior of the system in terms of constraints and build-time
consequences. </P
><P
>In <SPAN
CLASS="APPLICATION"
>CDL</SPAN
> the value of an option consists of two parts. There is a
boolean part, controlling whether or not the option is enabled. There
is also a data part, providing additional information. For most
options one of these parts is fixed, as controlled by the option's
<SPAN
CLASS="PROPERTY"
>flavor</SPAN
> property:</P
><DIV
CLASS="INFORMALTABLE"
><A
NAME="AEN1413"><P
></P
><TABLE
BORDER="1"
CLASS="CALSTABLE"
><THEAD
><TR
><TH
ALIGN="LEFT"
VALIGN="TOP"
>Flavor</TH
><TH
ALIGN="LEFT"
VALIGN="TOP"
>Enabled</TH
><TH
ALIGN="LEFT"
VALIGN="TOP"
>Data</TH
></TR
></THEAD
><TBODY
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
><TT
CLASS="LITERAL"
>none</TT
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
>Always enabled</TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><TT
CLASS="LITERAL"
>1</TT
>, not modifiable</TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
><TT
CLASS="LITERAL"
>bool</TT
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
>User-modifiable</TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><TT
CLASS="LITERAL"
>1</TT
>, not modifiable</TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
><TT
CLASS="LITERAL"
>data</TT
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
>Always enabled</TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
>User-modifiable</TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
><TT
CLASS="LITERAL"
>booldata</TT
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
>User-modifiable</TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
>User-modifiable</TD
></TR
></TBODY
></TABLE
><P
></P
></DIV
><P
>The effects of the boolean and data parts are as follows:</P
><P
></P
><OL
TYPE="1"
><LI
><P
>If an option is disabled, in other words if the boolean part is false,
then any references to that option in <SPAN
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -