URL
https://opencores.org/ocsvn/openrisc_2011-10-31/openrisc_2011-10-31/trunk
Subversion Repositories openrisc_2011-10-31
[/] [openrisc/] [trunk/] [rtos/] [ecos-2.0/] [doc/] [html/] [cdl-guide/] [ref.active-if.html] - Rev 369
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
>active_if</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="CDL Language Specification"
HREF="reference.html"><LINK
REL="PREVIOUS"
TITLE="cdl_interface"
HREF="ref.cdl-interface.html"><LINK
REL="NEXT"
TITLE="calculated"
HREF="ref.calculated.html"></HEAD
><BODY
CLASS="REFENTRY"
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="ref.cdl-interface.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="ref.calculated.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><H1
><A
NAME="REF.ACTIVE-IF"><SPAN
CLASS="PROPERTY"
>active_if</SPAN
></H1
><DIV
CLASS="REFNAMEDIV"
><A
NAME="AEN3662"
></A
><H2
>Name</H2
>Property <SPAN
CLASS="PROPERTY"
>active_if</SPAN
> -- Allow additional control over the active state of an
option or other CDL entity.</DIV
><DIV
CLASS="REFSYNOPSISDIV"
><A
NAME="AEN3666"><H2
>Synopsis</H2
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="SYNOPSIS"
>cdl_option <name> {
active_if <condition>
…
}</PRE
></TD
></TR
></TABLE
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN3668"
></A
><H2
>Description</H2
><P
>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
<TT
CLASS="LITERAL"
>CYGDBG_INFRA_DEBUG_PRECONDITIONS</TT
>, which exists
below the component <TT
CLASS="LITERAL"
>CYGDBG_USE_ASSERT</TT
>. 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 <SPAN
CLASS="PROPERTY"
>requires</SPAN
> constraints associated with
preconditions are irrelevant; any <SPAN
CLASS="PROPERTY"
>compile</SPAN
> property or other
build-related property is ignored.</P
><P
>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
<TT
CLASS="LITERAL"
>CYGPKG_LIBM</TT
> package in the overall hierarchy, but
should be inactive unless there is appropriate hardware support. In
cases like this an <SPAN
CLASS="PROPERTY"
>active_if</SPAN
> property is appropriate.</P
><P
>Another common use of <SPAN
CLASS="PROPERTY"
>active_if</SPAN
> 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
<SPAN
CLASS="PROPERTY"
>active_if</SPAN
> dependency on A.</P
><P
><SPAN
CLASS="PROPERTY"
>active_if</SPAN
> takes a goal expression as argument. For details of goal
expression syntax see <A
HREF="language.values.html#LANGUAGE.GOAL-EXPRESSION"
>the Section called <I
>Goal Expressions</I
> in Chapter 3</A
>. 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 <SPAN
CLASS="PROPERTY"
>active_if</SPAN
>
conditions in a single option, in which case all of the conditions
have to be satisfied if the option is to be active.</P
><P
>The <SPAN
CLASS="PROPERTY"
>active_if</SPAN
> and <SPAN
CLASS="PROPERTY"
>requires</SPAN
> 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 <TT
CLASS="LITERAL"
>active_if A</TT
> or as
<TT
CLASS="LITERAL"
>requires A</TT
>. The points to note are:</P
><P
></P
><UL
><LI
><P
>If <TT
CLASS="LITERAL"
>active_if A</TT
> 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.</P
></LI
><LI
><P
>If <TT
CLASS="LITERAL"
>requires A</TT
> 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.</P
></LI
><LI
><P
>If there are hardware dependencies then an <SPAN
CLASS="PROPERTY"
>active_if</SPAN
> 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
<TT
CLASS="LITERAL"
>active_if CYGPKG_NET</TT
> 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. </P
></LI
><LI
><P
>If option B exists to provide additional debugging information about
the functionality provided by A then again an <SPAN
CLASS="PROPERTY"
>active_if</SPAN
> constraint
is appropriate. There is no point in letting users enable extra
debugging facilities for a feature that is not actually present.</P
></LI
><LI
><P
>The configuration system's inference engine will cope equally well
with <SPAN
CLASS="PROPERTY"
>active_if</SPAN
> and <SPAN
CLASS="PROPERTY"
>requires</SPAN
> properties. Suppose there is a
conflict because some third option depends on B. If B is
<TT
CLASS="LITERAL"
>active_if A</TT
> then the inference engine will
attempt to make A active and enabled, and then to enable B if
necessary. If B <TT
CLASS="LITERAL"
>requires A</TT
> 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.</P
></LI
></UL
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN3710"
></A
><H2
>Example</H2
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
># 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
…
}</PRE
></TD
></TR
></TABLE
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN3713"
></A
><H2
>See Also</H2
><P
>Property <A
HREF="ref.requires.html"
><SPAN
CLASS="PROPERTY"
>requires</SPAN
></A
>.</P
></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="ref.cdl-interface.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="ref.calculated.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><TT
CLASS="LITERAL"
>cdl_interface</TT
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="reference.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><SPAN
CLASS="PROPERTY"
>calculated</SPAN
></TD
></TR
></TABLE
></DIV
></BODY
></HTML
> Go to most recent revision | Compare with Previous | Blame | View Log