+++ /dev/null
-<!-- 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
->
\ No newline at end of file
projects / karo-tx-redboot.git / blobdiff