1 <!-- Copyright (C) 2003 Red Hat, Inc. -->
2 <!-- This material may be distributed only subject to the terms -->
3 <!-- and conditions set forth in the Open Publication License, v1.0 -->
4 <!-- or later (the latest version is presently available at -->
5 <!-- http://www.opencontent.org/openpub/). -->
6 <!-- Distribution of the work or derivative of the work in any -->
7 <!-- standard (paper) book form is prohibited unless prior -->
8 <!-- permission is obtained from the copyright holder. -->
13 ><meta name="MSSmartTagsPreventParsing" content="TRUE">
16 CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
19 TITLE="The eCos Component Writer's Guide"
20 HREF="cdl-guide.html"><LINK
22 TITLE="CDL Language Specification"
23 HREF="reference.html"><LINK
26 HREF="ref.cdl-interface.html"><LINK
29 HREF="ref.calculated.html"></HEAD
40 SUMMARY="Header navigation table"
52 > Component Writer's Guide</TH
60 HREF="ref.cdl-interface.html"
74 HREF="ref.calculated.html"
85 NAME="REF.ACTIVE-IF"><SPAN
99 > -- Allow additional control over the active state of an
100 option or other CDL entity.</DIV
102 CLASS="REFSYNOPSISDIV"
114 >cdl_option <name> {
115 active_if <condition>
130 >Configuration options or other entities may be either active or
131 inactive. Typically this is controlled by the option's location in the
132 overall hierarchy. Consider the option
135 >CYGDBG_INFRA_DEBUG_PRECONDITIONS</TT
137 below the component <TT
139 >CYGDBG_USE_ASSERT</TT
141 component is disabled then the options it contains are inactive: there
142 is no point in enabling preconditions unless there is generic
143 assertion support; any <SPAN
146 > constraints associated with
147 preconditions are irrelevant; any <SPAN
151 build-related property is ignored.</P
153 >In some cases the hierarchy does not provide sufficient control over
154 whether or not a particular option should be active. For example, the
155 math library could have support for floating point exceptions which
156 is only worthwhile if the hardware implements appropriate
157 functionality, as specified by the architectural HAL. The relevant
158 math library configuration options should remain below the
162 > package in the overall hierarchy, but
163 should be inactive unless there is appropriate hardware support. In
164 cases like this an <SPAN
167 > property is appropriate.</P
169 >Another common use of <SPAN
172 > properties is to avoid excessive
173 nesting in the configuration hierarchy. If some option B is only
174 relevant if option A is enabled, it is possible to turn A into a
175 component that contains B. However adding another level to the
176 hierarchy for a component which will contain just one entry may be
177 considered excessive. In such cases it is possible for B to have an
181 > dependency on A.</P
186 > takes a goal expression as argument. For details of goal
187 expression syntax see <A
188 HREF="language.values.html#LANGUAGE.GOAL-EXPRESSION"
189 >the Section called <I
193 most cases the goal expression will be very simple, often involving
194 just one other option, but more complicated expressions can be used
195 when appropriate. It is also possible to have multiple <SPAN
199 conditions in a single option, in which case all of the conditions
200 have to be satisfied if the option is to be active.</P
208 > properties have certain similarities,
209 but they serve a different purpose. Suppose there are two options A
210 and B, and option B relies on functionality provided by A. This could
211 be expressed as either <TT
213 >active_if A</TT
218 >. The points to note are:</P
226 >active_if A</TT
227 > is used and A is disabled or
228 inactive, then graphical tools will generally prevent any attempt at
229 modifying B. For example the text for B could be grayed out, and the
230 associated checkbutton (if B is a boolean option) would be disabled.
231 If the user needs the functionality provided by option B then it is
232 necessary to go to option A first and manipulate it appropriately.</P
239 > is used and A is disabled or
240 inactive, graphical tools will still allow B to be manipulated and
241 enabled. This would result in a new conflict which may get resolved
242 automatically or which may need user intervention.</P
246 >If there are hardware dependencies then an <SPAN
250 usually the preferred approach. There is no point in allowing the user
251 to manipulate a configuration option if the corresponding
252 functionality cannot possibly work on the currently-selected hardware.
253 Much the same argument applies to coarse-grained dependencies, for
254 example if an option depends on the presence of a TCP/IP stack then an
257 >active_if CYGPKG_NET</TT
258 > condition is appropriate:
259 it may be possible to satisfy the condition, but it requires the
260 fairly drastic step of loading another package; further more, if the
261 user wanted a TCP/IP stack in the configuration then it would probably
262 have been loaded already. </P
266 >If option B exists to provide additional debugging information about
267 the functionality provided by A then again an <SPAN
271 is appropriate. There is no point in letting users enable extra
272 debugging facilities for a feature that is not actually present.</P
276 >The configuration system's inference engine will cope equally well
283 > properties. Suppose there is a
284 conflict because some third option depends on B. If B is
287 >active_if A</TT
288 > then the inference engine will
289 attempt to make A active and enabled, and then to enable B if
294 engine will attempt to enable B and resolve the resulting conflict by
295 causing A to be both active and enabled. Although the inference occurs
296 in a different order, in most cases the effect will be the same.</P
314 CLASS="PROGRAMLISTING"
315 ># Do not provide extra semaphore debugging if there are no semaphores
316 cdl_option CYGDBG_KERNEL_INSTRUMENT_BINSEM {
317 active_if CYGPKG_KERNEL_SYNCH
321 # Avoid another level in the configuration hierarchy
322 cdl_option CYGSEM_KERNEL_SYNCH_MUTEX_PRIORITY_INHERITANCE_SIMPLE_RELAY {
323 active_if CYGSEM_KERNEL_SYNCH_MUTEX_PRIORITY_INHERITANCE_SIMPLE
327 # Functionality that is only relevant if another package is loaded
328 cdl_option CYGSEM_START_UITRON_COMPATIBILITY {
329 active_if CYGPKG_UITRON
333 # Check that the hardware or HAL provide the appropriate functionality
334 cdl_option CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT {
335 active_if CYGINT_HAL_DEBUG_GDB_STUBS_BREAK
351 HREF="ref.requires.html"
363 SUMMARY="Footer navigation table"
374 HREF="ref.cdl-interface.html"
383 HREF="cdl-guide.html"
392 HREF="ref.calculated.html"
411 HREF="reference.html"