URL
https://opencores.org/ocsvn/openrisc/openrisc/trunk
Subversion Repositories openrisc
[/] [openrisc/] [trunk/] [rtos/] [ecos-2.0/] [doc/] [html/] [cdl-guide/] [ref.active-if.html] - Rev 706
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