3 <!-- =============================================================== -->
5 <!-- reference.sgml -->
7 <!-- The man pages. -->
9 <!-- =============================================================== -->
10 <!-- ####COPYRIGHTBEGIN#### -->
12 <!-- =============================================================== -->
13 <!-- Copyright (C) 2000, 2001, 2002 Red Hat, Inc. -->
15 <!-- This material may be distributed only subject to the terms -->
16 <!-- and conditions set forth in the Open Publication License, v1.0 -->
17 <!-- or later (the latest version is presently available at -->
18 <!-- http://www.opencontent.org/openpub/) -->
19 <!-- Distribution of the work or derivative of the work in any -->
20 <!-- standard (paper) book form is prohibited unless prior -->
21 <!-- permission obtained from the copyright holder -->
22 <!-- =============================================================== -->
24 <!-- ####COPYRIGHTEND#### -->
25 <!-- =============================================================== -->
26 <!-- #####DESCRIPTIONBEGIN#### -->
28 <!-- Author(s): bartv -->
29 <!-- Contact(s): bartv -->
30 <!-- Date: 2000/02/06 -->
31 <!-- Version: 0.01 -->
33 <!-- ####DESCRIPTIONEND#### -->
34 <!-- =============================================================== -->
38 <chapter id="reference">
39 <title>CDL Language Specification</title>
42 This chapter contains reference information for the main &CDL;
43 commands &cdl-option;, &cdl-component;, &cdl-package; and
44 &cdl-interface;, followed by the various properties such as
45 &active-if; and &compile; in alphabetical order.
48 <!-- {{{ cdl_option -->
50 <refentry id="ref.cdl-option">
52 <refentrytitle>&cdl-option;</refentrytitle>
56 <refname>Command &cdl-option;</refname>
57 <refpurpose>Define a single configuration option</refpurpose>
62 cdl_option <name> {
68 <refsect1><title>Description</title>
70 The option is the basic unit of configurability. Generally each option
71 corresponds to a single user choice. Typically there is a certain
72 amount of information associated with an option to assist the user in
73 manipulating that option, for example a textual description. There
74 will also be some limits on the possible values that the user can
75 choose, so an option may be a simple yes-or-no choice or it may be
76 something more complicated such as an array size or a device name.
77 Options may have associated constraints, so if that option is enabled
78 then certain conditions have to satisfied elsewhere in the
79 configuration. Options usually have direct consequences such as
80 preprocessor <literal>#define</literal> symbols in a configuration
84 &cdl-option; is implemented as a Tcl command that takes two arguments,
85 a name and a body. The name must be a valid C preprocessor identifier:
86 a sequence of upper or lower case letters, digits or underscores,
87 starting with a non-digit character; identifiers beginning with an
88 underscore should normally be avoided because they may clash with
89 system packages or with identifiers reserved for use by the compiler.
90 Within a single configuration, names must be unique. If a
91 configuration contained two packages which defined the same entity
92 <literal>CYGIMP_SOME_OPTION</literal>, any references to that entity
93 in a &requires; property or any other expression
94 would be ambiguous. It is possible for a given name to be used by two
95 different packages if those packages should never be loaded into a
96 single configuration. For example, architectural HAL packages are
97 allowed to re-use names because a single configuration cannot target
98 two different architectures. For a recommended naming convention see
99 <xref linkend="package.contents">.
102 The second argument to <literal>cdl_option</literal> is a body of
103 properties, typically surrounded by braces so that the Tcl interpreter
104 treats it as a single argument. This body will be processed by a
105 recursive invocation of the Tcl interpreter, extended with additional
106 commands for the various properties that are allowed inside a
107 &cdl-option;. The valid properties are:
110 <variablelist TermLength=16>
112 <varlistentry><term><link linkend="ref.active-if">&active-if;</link></term>
114 Allow additional control over the active state of this option.
115 </para></listitem></varlistentry>
117 <varlistentry><term><link linkend="ref.calculated">&calculated;</link></term>
119 The option's value is not directly user-modifiable, it is calculated
120 using a suitable CDL expression.
121 </para></listitem></varlistentry>
123 <varlistentry><term><link linkend="ref.compile">&compile;</link></term>
125 List the source files that should be built if this option is active
127 </para></listitem></varlistentry>
129 <varlistentry><term><link linkend="ref.default-value">&default-value;</link></term>
131 Provide a default value for this option using a CDL expression.
132 </para></listitem></varlistentry>
134 <varlistentry><term><link linkend="ref.define">&define;</link></term>
136 Specify additional <literal>#define</literal> symbols that should go
137 into the owning package's configuration header file.
138 </para></listitem></varlistentry>
140 <varlistentry><term><link linkend="ref.define-format">&define-format;</link></term>
142 Control how the option's value will appear in the configuration header
144 </para></listitem></varlistentry>
146 <varlistentry><term><link linkend="ref.define-proc">&define-proc;</link></term>
148 Use a fragment of Tcl code to output additional data to
149 configuration header files.
150 </para></listitem></varlistentry>
152 <varlistentry><term><link linkend="ref.description">&description;</link></term>
154 Provide a textual description for this option.
155 </para></listitem></varlistentry>
157 <varlistentry><term><link linkend="ref.display">&display;</link></term>
159 Provide a short string describing this option.
160 </para></listitem></varlistentry>
162 <varlistentry><term><link linkend="ref.doc">&doc;</link></term>
164 The location of on-line documentation for this option.
165 </para></listitem></varlistentry>
167 <varlistentry><term><link linkend="ref.flavor">&flavor;</link></term>
169 Specify the nature of this option.
170 </para></listitem></varlistentry>
172 <varlistentry><term><link linkend="ref.if-define">&if-define;</link></term>
174 Output a common preprocessor construct to a configuration header file.
175 </para></listitem></varlistentry>
177 <varlistentry><term><link linkend="ref.implements">&implements;</link></term>
179 Enabling this option provides one instance of a more general
181 </para></listitem></varlistentry>
183 <varlistentry><term><link linkend="ref.legal-values">&legal-values;</link></term>
185 Impose constraints on the possible values for this option.
186 </para></listitem></varlistentry>
188 <varlistentry><term><link linkend="ref.make">&make;</link></term>
190 An additional custom build step associated with this option, resulting
191 in a target that should not go directly into a library.
192 </para></listitem></varlistentry>
194 <varlistentry><term><link linkend="ref.make-object">&make-object;</link></term>
196 An additional custom build step associated with this option, resulting
197 in an object file that should go into a library.
198 </para></listitem></varlistentry>
200 <varlistentry><term><link linkend="ref.no-define">&no-define;</link></term>
202 Suppress the normal generation of a preprocessor
203 <literal>#define</literal> symbol in a configuration header file.
204 </para></listitem></varlistentry>
206 <varlistentry><term><link linkend="ref.parent">&parent;</link></term>
208 Control the location of this option in the configuration hierarchy.
209 </para></listitem></varlistentry>
211 <varlistentry><term><link linkend="ref.requires">&requires;</link></term>
213 List constraints that the configuration should satisfy if this option is
215 </para></listitem></varlistentry>
221 <refsect1><title>Example</title>
222 <programlisting format="linespecific" width=72>
223 cdl_option CYGDBG_INFRA_DEBUG_PRECONDITIONS {
224 display "Preconditions"
227 This option allows individual control of preconditions.
228 A precondition is one type of assert, which it is
229 useful to control separately from more general asserts.
230 The function is CYG_PRECONDITION(condition,msg)."
235 <refsect1><title>See Also</title>
237 Command <link linkend="ref.cdl-component">&cdl-component;</link>,
238 command <link linkend="ref.cdl-package">&cdl-package;</link>,
239 command <link linkend="ref.cdl-interface">&cdl-interface;</link>.
246 <!-- {{{ cdl_component -->
248 <refentry id="ref.cdl-component">
250 <refentrytitle>&cdl-component;</refentrytitle>
254 <refname>Command &cdl-component;</refname>
255 <refpurpose>Define a component, a collection of configuration options</refpurpose>
260 cdl_component <name> {
266 <refsect1><title>Description</title>
268 A component is a configuration option that can contain additional
269 options and sub-components. The body of a &cdl-component; can contain
270 the same properties as that of a &cdl-option;. There is an additional
271 property, &script; which allows configuration data to be split into
272 multiple files. It is also possible for a component body to include
273 &cdl-component;, &cdl-option; and &cdl-interface; entities that should
274 go below this component in the configuration hierarchy.
277 &cdl-component; is implemented as a Tcl command that takes two
278 arguments, a name and a body. The name must be a valid C preprocessor
279 identifier: a sequence of upper or lower case letters, digits or
280 underscores, starting with a non-digit character; identifiers
281 beginning with an underscore should normally be avoided because they
282 may clash with system packages or with identifiers reserved for use by
283 the compiler. Within a single configuration, names must be unique. If
284 a configuration contained two packages which defined the same entity
285 <literal>CYGIMP_SOME_OPTION</literal>, any references to that entity
286 in a &requires; property or any other expression would be ambiguous.
287 It is possible for a given name to be used by two different packages
288 if those packages should never be loaded into a single configuration.
289 For example, architectural HAL packages are allowed to re-use certain
290 names because a single configuration cannot target two different
291 architectures. For a recommended naming convention see <xref
292 linkend="package.contents">.
295 The second argument to &cdl-component; is a body of properties and
296 other commands, typically surrounded by braces so that the Tcl
297 interpreter treats it as a single argument. This body will be
298 processed by a recursive invocation of the Tcl interpreter, extended
299 with additional commands for the various properties that are allowed
300 inside a &cdl-component;. The valid commands are:
303 <variablelist TermLength=16>
305 <varlistentry><term><link linkend="ref.active-if">&active-if;</link></term>
307 Allow additional control over the active state of this component.
308 </para></listitem></varlistentry>
310 <varlistentry><term><link linkend="ref.calculated">&calculated;</link></term>
312 The component's value is not directly user-modifiable, it is calculated
313 using a suitable CDL expression.
314 </para></listitem></varlistentry>
316 <varlistentry><term><link linkend="ref.cdl-component">&cdl-component</link></term>
318 Define a sub-component.
319 </para></listitem></varlistentry>
321 <varlistentry><term><link linkend="ref.cdl-interface">&cdl-interface;</link></term>
323 Define an interface which should appear immediately below this
324 component in the configuration hierarchy.
325 </para></listitem></varlistentry>
327 <varlistentry><term><link linkend="ref.cdl-option">&cdl-option;</link></term>
329 Define a configuration option which should appear immediately below
330 this component in the configuration hierarchy.
331 </para></listitem></varlistentry>
333 <varlistentry><term><link linkend="ref.compile">&compile;</link></term>
335 List the source files that should be built if this component is active
337 </para></listitem></varlistentry>
339 <varlistentry><term><link linkend="ref.default-value">&default-value;</link></term>
341 Provide a default value for this component using a CDL expression.
342 </para></listitem></varlistentry>
344 <varlistentry><term><link linkend="ref.define">&define;</link></term>
346 Specify additional <literal>#define</literal> symbols that should go
347 into the owning package's configuration header file.
348 </para></listitem></varlistentry>
350 <varlistentry><term><link linkend="ref.define-format">&define-format;</link></term>
352 Control how the component's value will appear in the configuration header
354 </para></listitem></varlistentry>
356 <varlistentry><term><link linkend="ref.define-proc">&define-proc;</link></term>
358 Use a fragment of Tcl code to output additional data to
359 configuration header files.
360 </para></listitem></varlistentry>
362 <varlistentry><term><link linkend="ref.description">&description;</link></term>
364 Provide a textual description for this component.
365 </para></listitem></varlistentry>
367 <varlistentry><term><link linkend="ref.display">&display;</link></term>
369 Provide a short string describing this component.
370 </para></listitem></varlistentry>
372 <varlistentry><term><link linkend="ref.doc">&doc;</link></term>
374 The location of on-line documentation for this component.
375 </para></listitem></varlistentry>
377 <varlistentry><term><link linkend="ref.flavor">&flavor;</link></term>
379 Specify the nature of this component.
380 </para></listitem></varlistentry>
382 <varlistentry><term><link linkend="ref.if-define">&if-define;</link></term>
384 Output a common preprocessor construct to a configuration header file.
385 </para></listitem></varlistentry>
387 <varlistentry><term><link linkend="ref.implements">&implements;</link></term>
389 Enabling this component provides one instance of a more general
391 </para></listitem></varlistentry>
393 <varlistentry><term><link linkend="ref.legal-values">&legal-values;</link></term>
395 Impose constraints on the possible values for this component.
396 </para></listitem></varlistentry>
398 <varlistentry><term><link linkend="ref.make">&make;</link></term>
400 An additional custom build step associated with this component, resulting
401 in a target that should not go directly into a library.
402 </para></listitem></varlistentry>
404 <varlistentry><term><link linkend="ref.make-object">&make-object;</link></term>
406 An additional custom build step associated with this component, resulting
407 in an object file that should go into a library.
408 </para></listitem></varlistentry>
410 <varlistentry><term><link linkend="ref.no-define">&no-define;</link></term>
412 Suppress the normal generation of a preprocessor
413 <literal>#define</literal> symbol in a configuration header file.
414 </para></listitem></varlistentry>
416 <varlistentry><term><link linkend="ref.parent">&parent;</link></term>
418 Control the location of this component in the configuration hierarchy.
419 </para></listitem></varlistentry>
421 <varlistentry><term><link linkend="ref.requires">&requires;</link></term>
423 List constraints that the configuration should satisfy if this component is
425 </para></listitem></varlistentry>
427 <varlistentry><term><link linkend="ref.script">&script;</link></term>
429 Include additional configuration information from another
431 </para></listitem></varlistentry>
437 <refsect1><title>Example</title>
439 <programlisting format="linespecific" width=72>
440 cdl_component CYGDBG_USE_ASSERTS {
441 display "Use asserts"
444 If this component is enabled, assertions in the code are
445 tested at run-time. Assert functions (CYG_ASSERT()) are
446 defined in 'include/cyg/infra/cyg_ass.h' within the 'install'
447 tree. If the component is disabled, these result in no
448 additional object code and no checking of the asserted
456 <refsect1><title>See Also</title>
458 Command <link linkend="ref.cdl-option">&cdl-option;</link>,
459 command <link linkend="ref.cdl-package">&cdl-package;</link>,
460 command <link linkend="ref.cdl-interface">&cdl-interface;</link>.
467 <!-- {{{ cdl_package -->
469 <refentry id="ref.cdl-package">
471 <refentrytitle>&cdl-package;</refentrytitle>
475 <refname>Command &cdl-package;</refname>
476 <refpurpose>Define a package, a component that can be distributed</refpurpose>
481 cdl_package <name> {
487 <refsect1><title>Description</title>
489 A package is a unit of distribution. It is also a configuration option
490 in that users can choose whether or not a particular package is loaded
491 into the configuration, and which version of that package should be
492 loaded. It is also a component in that it can contain additional
493 components and options in a hierarchy.
496 The top-level &CDL; script for a package should begin with a &cdl-package;
497 command. This can contain most of the properties that can be used in a
498 &cdl-option; command, and a number of additional ones which apply to a
499 package as a whole. It is also possible to include &cdl-component;,
500 &cdl-interface; and &cdl-option; commands in the body of a package.
501 However all configuration entities that occur at the top level of the
502 script containing the &cdl-package; command are automatically placed
503 below that package in the configuration hierarchy, so putting them
504 inside the body has no effect.
507 The following properties cannot be used in the body of a &cdl-package;
510 <variablelist TermLength=16>
512 <varlistentry><term>&flavor;</term>
514 Packages always have the flavor <literal>booldata</literal>.
515 </para></listitem></varlistentry>
517 <varlistentry><term>&default-value;</term>
519 The value of a package is its version number. This is specified at the
520 time the package is loaded into the configuration, and cannot be
521 calculated afterwards. Typically the most recent version of the
522 package will be loaded.
523 </para></listitem></varlistentry>
525 <varlistentry><term>&legal-values;</term>
527 The legal values list for a given package is determined by which
528 versions of that package are installed in the component repository,
529 and cannot be further constrained in the CDL scripts.
530 </para></listitem></varlistentry>
532 <varlistentry><term>&calculated;</term>
534 The value of a package is always selected at the time that it is
535 loaded into the configuration, and cannot be re-calculated afterwards.
536 </para></listitem></varlistentry>
538 <varlistentry><term>&script;</term>
540 This would be redundant since the CDL script containing the
541 &cdl-package; command acts as that package's script.
542 </para></listitem></varlistentry>
547 &cdl-package; is implemented as a Tcl command that takes two
548 arguments, a name and a body. The name must be a valid C preprocessor
549 identifier: a sequence of upper or lower case letters, digits or
550 underscores, starting with a non-digit character; identifiers
551 beginning with an underscore should normally be avoided because they
552 may clash with system packages or with identifiers reserved for use by
553 the compiler. Packages should always have unique names within a given
554 component repository. For a recommended naming convention see <xref
555 linkend="package.contents">.
558 The second argument to &cdl-package; is a body of properties and other
559 commands, typically surrounded by braces so that the Tcl interpreter
560 treats it as a single argument. This body will be processed by a
561 recursive invocation of the Tcl interpreter, extended with additional
562 commands for the various properties that are allowed inside a
563 &cdl-package;. The valid commands are:
566 <variablelist TermLength=16>
568 <varlistentry><term><link linkend="ref.active-if">&active-if;</link></term>
570 Allow additional control over the active state of this package.
571 </para></listitem></varlistentry>
573 <varlistentry><term><link linkend="ref.cdl-component">&cdl-component;</link></term>
575 Define a component which should appear immediately below this package
576 in the configuration hierarchy.
577 </para></listitem></varlistentry>
579 <varlistentry><term><link linkend="ref.cdl-interface">&cdl-interface;</link></term>
581 Define an interface which should appear immediately below this
582 package in the configuration hierarchy.
583 </para></listitem></varlistentry>
585 <varlistentry><term><link linkend="ref.cdl-option">&cdl-option;</link></term>
587 Define an option which should appear immediately below
588 this package in the configuration hierarchy.
589 </para></listitem></varlistentry>
591 <varlistentry><term><link linkend="ref.compile">&compile;</link></term>
593 List the source files that should be built for this package.
594 </para></listitem></varlistentry>
596 <varlistentry><term><link linkend="ref.define">&define;</link></term>
598 Specify additional <literal>#define</literal> symbols that should go
599 into the package's configuration header file.
600 </para></listitem></varlistentry>
602 <varlistentry><term><link linkend="ref.define-format">&define-format;</link></term>
604 Control how the package's value will appear in the global
605 configuration header file <filename
606 class="headerfile">pkgconf/system.h</filename>
607 </para></listitem></varlistentry>
609 <varlistentry><term><link linkend="ref.define-header">&define-header;</link></term>
611 Specify the configuration header file that will be generated for this package.
612 </para></listitem></varlistentry>
614 <varlistentry><term><link linkend="ref.define-proc">&define-proc;</link></term>
616 Use a fragment of Tcl code to output additional data to
617 configuration header files.
618 </para></listitem></varlistentry>
620 <varlistentry><term><link linkend="ref.description">&description;</link></term>
622 Provide a textual description for this component.
623 </para></listitem></varlistentry>
625 <varlistentry><term><link linkend="ref.display">&display;</link></term>
627 Provide a short string describing this component.
628 </para></listitem></varlistentry>
630 <varlistentry><term><link linkend="ref.doc">&doc;</link></term>
632 The location of on-line documentation for this component.
633 </para></listitem></varlistentry>
635 <varlistentry><term><link linkend="ref.hardware">&hardware;</link></term>
637 This package is tied to specific hardware.
638 </para></listitem></varlistentry>
640 <varlistentry><term><link linkend="ref.if-define">&if-define;</link></term>
642 Output a common preprocessor construct to a configuration header file.
643 </para></listitem></varlistentry>
645 <varlistentry><term><link linkend="ref.implements">&implements;</link></term>
647 Enabling this component provides one instance of a more general
649 </para></listitem></varlistentry>
651 <varlistentry><term><link linkend="ref.include-dir">&include-dir;</link></term>
653 Specify the desired location of this package's exported header files in
655 </para></listitem></varlistentry>
657 <varlistentry><term><link linkend="ref.include-files">&include-files;</link></term>
659 List the header files that are exported by this package.
660 </para></listitem></varlistentry>
662 <varlistentry><term><link linkend="ref.library">&library;</link></term>
664 Specify which library should contain the object files
665 generated by building this package.
666 </para></listitem></varlistentry>
668 <varlistentry><term><link linkend="ref.make">&make;</link></term>
670 An additional custom build step associated with this component, resulting
671 in a target that should not go directly into a library.
672 </para></listitem></varlistentry>
674 <varlistentry><term><link linkend="ref.make-object">&make-object;</link></term>
676 An additional custom build step associated with this component, resulting
677 in an object file that should go into a library.
678 </para></listitem></varlistentry>
680 <varlistentry><term><link linkend="ref.no-define">&no-define;</link></term>
682 Suppress the normal generation of the package's
683 <literal>#define</literal> in the global configuration header file
684 <filename class="headerfile">pkgconf/system.h</filename>.
685 </para></listitem></varlistentry>
687 <varlistentry><term><link linkend="ref.parent">&parent;</link></term>
689 Control the location of this package in the configuration hierarchy.
690 </para></listitem></varlistentry>
692 <varlistentry><term><link linkend="ref.requires">&requires;</link></term>
694 List constraints that the configuration should satisfy if this package is
696 </para></listitem></varlistentry>
703 <refsect1><title>Example</title>
704 <programlisting format="linespecific" width=72>
705 cdl_package CYGPKG_INFRA {
706 display "Infrastructure"
707 include_dir cyg/infra
709 Common types and useful macros.
710 Tracing and assertion facilities.
711 Package startup options."
713 compile startup.cxx prestart.cxx pkgstart.cxx userstart.cxx \
714 dummyxxmain.cxx null.cxx simple.cxx fancy.cxx buffer.cxx \
715 diag.cxx tcdiag.cxx memcpy.c memset.c delete.cxx
721 <refsect1><title>See Also</title>
723 Command <link linkend="ref.cdl-option">&cdl-option;</link>,
724 command <link linkend="ref.cdl-component">&cdl-component;</link>,
725 command <link linkend="ref.cdl-interface">&cdl-interface;</link>.
732 <!-- {{{ cdl_interface -->
734 <refentry id="ref.cdl-interface">
736 <refentrytitle>&cdl-interface;</refentrytitle>
740 <refname>Command &cdl-interface;</refname>
741 <refpurpose>Define an interface, functionality that can be provided by
742 a number of different implementations.</refpurpose>
747 cdl_interface <name> {
753 <refsect1><title>Description</title>
755 An interface is a special type of calculated configuration option.
756 It provides an abstraction mechanism that is often useful in &CDL;
757 expressions. As an example, suppose that some package relies on the
758 presence of code that implements the standard kernel scheduling
759 interface. However the requirement is no more stringent than this, so
760 the constraint can be satisfied by the mlqueue scheduler, the bitmap
761 scheduler, or any additional schedulers that may get implemented in
762 future. A first attempt at expressing the dependency might be:
764 <programlisting width=72>
765 requires CYGSEM_KERNEL_SCHED_MLQUEUE || CYGSEM_KERNEL_SCHED_BITMAP
768 This constraint is limited, it may need to be changed if a new
769 scheduler were to be added to the system. Interfaces provide a way of
770 expressing more general relationships:
772 <programlisting width=72>
773 requires CYGINT_KERNEL_SCHEDULER
776 The interface <literal>CYGINT_KERNEL_SCHEDULER</literal> is
777 <emphasis>implemented</emphasis> by both the mlqueue and bitmap
778 schedulers, and may be implemented by future schedulers as well. The
779 value of an interface is the number of implementors that are active
780 and enabled, so in a typical configuration only one scheduler will be
781 in use and the value of the interface will be <literal>1</literal>. If
782 all schedulers are disabled then the interface will have a value
783 <literal>0</literal> and the &requires; constraint will not be
787 Some component writers may prefer to use the first &requires;
788 constraint on the grounds that the code will only have been tested
789 with the mlqueue and bitmap schedulers and cannot be guaranteed to
790 work with any new schedulers. Other component writers may take a more
791 optimistic view and assume that their code will work with any
792 scheduler until proven otherwise.
795 Interfaces must be defined in CDL scripts, just like options,
796 components and packages. This involves the command &cdl-interface;
797 which takes two arguments, a name and a body. The name must be a valid
798 C preprocessor identifier: a sequence of upper or lower case letters,
799 digits or underscores, starting with a non-digit character;
800 identifiers beginning with an underscore should normally be avoided
801 because they may clash with system packages or with identifiers
802 reserved for use by the compiler. Within a single configuration, names
803 must be unique. If a configuration contained two packages which
804 defined the same entity <literal>CYGIMP_SOME_OPTION</literal>, any
805 references to that entity in a &requires; property or any other
806 expression would be ambiguous. It is possible for a given name to be
807 used by two different packages if those packages should never be
808 loaded into a single configuration. For example, architectural HAL
809 packages are allowed to re-use names because a single configuration
810 cannot target two different architectures. For a recommended naming
811 convention see <xref linkend="package.contents">.
814 The second argument to &cdl-interface; is a body of properties,
815 typically surrounded by braces so that the Tcl interpreter treats it
816 as a single argument. This body will be processed by a recursive
817 invocation of the Tcl interpreter, extended with additional commands
818 for the various properties that are allowed inside a &cdl-interface;.
819 The valid properties are a subset of those for a &cdl-option;.
822 <variablelist TermLength=16>
824 <varlistentry><term><link linkend="ref.active-if">&active-if;</link></term>
826 Allow additional control over the active state of this interface.
827 </para></listitem></varlistentry>
829 <varlistentry><term><link linkend="ref.compile">&compile;</link></term>
831 List the source files that should be built if this interface is active.
832 </para></listitem></varlistentry>
834 <varlistentry><term><link linkend="ref.define">&define;</link></term>
836 Specify additional <literal>#define</literal> symbols that should go
837 into the owning package's configuration header file.
838 </para></listitem></varlistentry>
840 <varlistentry><term><link linkend="ref.define-format">&define-format;</link></term>
842 Control how the interface's value will appear in the configuration header
844 </para></listitem></varlistentry>
846 <varlistentry><term><link linkend="ref.define-proc">&define-proc;</link></term>
848 Use a fragment of Tcl code to output additional data to
849 configuration header files.
850 </para></listitem></varlistentry>
852 <varlistentry><term><link linkend="ref.description">&description;</link></term>
854 Provide a textual description for this interface.
855 </para></listitem></varlistentry>
857 <varlistentry><term><link linkend="ref.display">&display;</link></term>
859 Provide a short string describing this interface.
860 </para></listitem></varlistentry>
862 <varlistentry><term><link linkend="ref.doc">&doc;</link></term>
864 The location of on-line documentation for this interface.
865 </para></listitem></varlistentry>
867 <varlistentry><term><link linkend="ref.flavor">&flavor;</link></term>
869 Interfaces have the <literal>data</literal> flavor by default, but
870 they can also be given the <literal>bool</literal> or
871 <literal>booldata</literal> flavor when necessary. A
872 <literal>bool</literal> interface is disabled if there are no active
873 and enabled implementors, otherwise it is enabled. A
874 <literal>booldata</literal> interface is also disabled if there are no
875 active and enabled implementors, otherwise it is enabled and the data
876 is a number corresponding to the number of these implementors.
877 </para></listitem></varlistentry>
879 <varlistentry><term><link linkend="ref.if-define">&if-define;</link></term>
881 Output a common preprocessor construct to a configuration header file.
882 </para></listitem></varlistentry>
884 <varlistentry><term><link linkend="ref.implements">&implements;</link></term>
886 If this interface is active it provides one instance of a more general
888 </para></listitem></varlistentry>
890 <varlistentry><term><link linkend="ref.legal-values">&legal-values;</link></term>
892 Interfaces always have a small numerical value. The &legal-values; can
893 be used to apply additional constraints such as an upper limit.
894 </para></listitem></varlistentry>
896 <varlistentry><term><link linkend="ref.make">&make;</link></term>
898 An additional custom build step associated with this option, resulting
899 in a target that should not go directly into a library.
900 </para></listitem></varlistentry>
902 <varlistentry><term><link linkend="ref.make-object">&make-object;</link></term>
904 An additional custom build step associated with this option, resulting
905 in an object file that should go into a library.
906 </para></listitem></varlistentry>
908 <varlistentry><term><link linkend="ref.no-define">&no-define;</link></term>
910 Suppress the normal generation of a preprocessor
911 <literal>#define</literal> symbol in a configuration header file.
912 </para></listitem></varlistentry>
914 <varlistentry><term><link linkend="ref.parent">&parent;</link></term>
916 Control the location of this option in the configuration hierarchy.
917 </para></listitem></varlistentry>
919 <varlistentry><term><link linkend="ref.requires">&requires;</link></term>
921 List constraints that the configuration should satisfy if this option is
923 </para></listitem></varlistentry>
928 A number of properties are not applicable to interfaces:
932 <varlistentry><term><link linkend="ref.calculated">&calculated;</link></term>
934 Interfaces are always calculated, based on the number of active and
935 enabled entities that implement the interface.
936 </para></listitem></varlistentry>
938 <varlistentry><term><link linkend="ref.default-value">&default-value;</link></term>
940 Interface values are calculated so a &default-value; property would be
942 </para></listitem></varlistentry>
947 Interfaces are not containers, so they cannot hold other entities such
948 as options or components.
951 A commonly used constraint on interface values takes the form:
953 <programlisting width=72>
954 requires CYGINT_KERNEL_SCHEDULER == 1
957 This constraint specifies that there can be only one scheduler in the
958 system. In some circumstances it is possible for the configuration
959 tools to detect this pattern and act accordingly, so for example
960 enabling the bitmap scheduler would automatically disable the mlqueue
966 <refsect1><title>Example</title>
967 <programlisting width=72>
968 cdl_interface CYGINT_KERNEL_SCHEDULER {
969 display "Number of schedulers in this configuration"
970 requires 1 == CYGINT_KERNEL_SCHEDULER
975 <refsect1><title>See Also</title>
977 Property <link linkend="ref.implements">&implements;</link>,
978 command <link linkend="ref.cdl-option">&cdl-option;</link>.
979 command <link linkend="ref.cdl-component">&cdl-component;</link>,
980 command <link linkend="ref.cdl-package">&cdl-package;</link>.
988 <!-- {{{ active_if -->
990 <refentry id="ref.active-if">
992 <refentrytitle>&active-if;</refentrytitle>
996 <refname>Property &active-if;</refname>
997 <refpurpose>Allow additional control over the active state of an
998 option or other CDL entity.</refpurpose>
1003 cdl_option <name> {
1004 active_if <condition>
1010 <refsect1><title>Description</title>
1012 Configuration options or other entities may be either active or
1013 inactive. Typically this is controlled by the option's location in the
1014 overall hierarchy. Consider the option
1015 <literal>CYGDBG_INFRA_DEBUG_PRECONDITIONS</literal>, which exists
1016 below the component <literal>CYGDBG_USE_ASSERT</literal>. If the whole
1017 component is disabled then the options it contains are inactive: there
1018 is no point in enabling preconditions unless there is generic
1019 assertion support; any &requires; constraints associated with
1020 preconditions are irrelevant; any &compile; property or other
1021 build-related property is ignored.
1024 In some cases the hierarchy does not provide sufficient control over
1025 whether or not a particular option should be active. For example, the
1026 math library could have support for floating point exceptions which
1027 is only worthwhile if the hardware implements appropriate
1028 functionality, as specified by the architectural HAL. The relevant
1029 math library configuration options should remain below the
1030 <literal>CYGPKG_LIBM</literal> package in the overall hierarchy, but
1031 should be inactive unless there is appropriate hardware support. In
1032 cases like this an &active-if; property is appropriate.
1035 Another common use of &active-if; properties is to avoid excessive
1036 nesting in the configuration hierarchy. If some option B is only
1037 relevant if option A is enabled, it is possible to turn A into a
1038 component that contains B. However adding another level to the
1039 hierarchy for a component which will contain just one entry may be
1040 considered excessive. In such cases it is possible for B to have an
1041 &active-if; dependency on A.
1044 &active-if; takes a goal expression as argument. For details of goal
1045 expression syntax see <xref linkend="language.goal-expression">. In
1046 most cases the goal expression will be very simple, often involving
1047 just one other option, but more complicated expressions can be used
1048 when appropriate. It is also possible to have multiple &active-if;
1049 conditions in a single option, in which case all of the conditions
1050 have to be satisfied if the option is to be active.
1053 The &active-if; and &requires; properties have certain similarities,
1054 but they serve a different purpose. Suppose there are two options A
1055 and B, and option B relies on functionality provided by A. This could
1056 be expressed as either <literal>active_if A</literal> or as
1057 <literal>requires A</literal>. The points to note are:
1062 If <literal>active_if A</literal> is used and A is disabled or
1063 inactive, then graphical tools will generally prevent any attempt at
1064 modifying B. For example the text for B could be grayed out, and the
1065 associated checkbutton (if B is a boolean option) would be disabled.
1066 If the user needs the functionality provided by option B then it is
1067 necessary to go to option A first and manipulate it appropriately.
1071 If <literal>requires A</literal> is used and A is disabled or
1072 inactive, graphical tools will still allow B to be manipulated and
1073 enabled. This would result in a new conflict which may get resolved
1074 automatically or which may need user intervention.
1078 If there are hardware dependencies then an &active-if; condition is
1079 usually the preferred approach. There is no point in allowing the user
1080 to manipulate a configuration option if the corresponding
1081 functionality cannot possibly work on the currently-selected hardware.
1082 Much the same argument applies to coarse-grained dependencies, for
1083 example if an option depends on the presence of a TCP/IP stack then an
1084 <literal>active_if CYGPKG_NET</literal> condition is appropriate:
1085 it may be possible to satisfy the condition, but it requires the
1086 fairly drastic step of loading another package; further more, if the
1087 user wanted a TCP/IP stack in the configuration then it would probably
1088 have been loaded already. </para></listitem>
1091 If option B exists to provide additional debugging information about
1092 the functionality provided by A then again an &active-if; constraint
1093 is appropriate. There is no point in letting users enable extra
1094 debugging facilities for a feature that is not actually present.
1098 The configuration system's inference engine will cope equally well
1099 with &active-if; and &requires; properties. Suppose there is a
1100 conflict because some third option depends on B. If B is
1101 <literal>active_if A</literal> then the inference engine will
1102 attempt to make A active and enabled, and then to enable B if
1103 necessary. If B <literal>requires A</literal> then the inference
1104 engine will attempt to enable B and resolve the resulting conflict by
1105 causing A to be both active and enabled. Although the inference occurs
1106 in a different order, in most cases the effect will be the same.
1113 <refsect1><title>Example</title>
1114 <programlisting width=72>
1115 # Do not provide extra semaphore debugging if there are no semaphores
1116 cdl_option CYGDBG_KERNEL_INSTRUMENT_BINSEM {
1117 active_if CYGPKG_KERNEL_SYNCH
1121 # Avoid another level in the configuration hierarchy
1122 cdl_option CYGSEM_KERNEL_SYNCH_MUTEX_PRIORITY_INHERITANCE_SIMPLE_RELAY {
1123 active_if CYGSEM_KERNEL_SYNCH_MUTEX_PRIORITY_INHERITANCE_SIMPLE
1127 # Functionality that is only relevant if another package is loaded
1128 cdl_option CYGSEM_START_UITRON_COMPATIBILITY {
1129 active_if CYGPKG_UITRON
1133 # Check that the hardware or HAL provide the appropriate functionality
1134 cdl_option CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT {
1135 active_if CYGINT_HAL_DEBUG_GDB_STUBS_BREAK
1141 <refsect1><title>See Also</title>
1143 Property <link linkend="ref.requires">&requires;</link>.
1150 <!-- {{{ calculated -->
1152 <refentry id="ref.calculated">
1154 <refentrytitle>&calculated;</refentrytitle>
1158 <refname>Property &calculated;</refname>
1159 <refpurpose>Used if the current option's value is not user-modifiable,
1160 but is calculated using a suitable CDL expression.</refpurpose>
1165 cdl_option <name> {
1166 calculated <expression>
1172 <refsect1><title>Description</title>
1174 In some cases it is useful to have a configuration option whose value
1175 cannot be modified directly by the user. This can be achieved using a
1176 &calculated;, which takes a CDL expression as argument (see <xref
1177 linkend="language.expression"> for a description of expression
1178 syntax). The configuration system evaluates the expression when the
1179 current package is loaded and whenever there is a change to any other
1180 option referenced in the expression. The result depends on the
1184 <variablelist TermLength=16>
1186 <varlistentry><term><literal>flavor none</literal></term>
1188 Options with this flavor have no value, so the &calculated;
1189 property is not applicable.
1190 </para></listitem></varlistentry>
1192 <varlistentry><term><literal>flavor bool</literal></term>
1194 If the expression evaluates to a non-zero result the option is
1195 enabled, otherwise it is disabled.
1196 </para></listitem></varlistentry>
1198 <varlistentry><term><literal>flavor booldata</literal></term>
1200 If the result of evaluating the expression is zero then the option is
1201 disabled, otherwise the option is enabled and its value is the result.
1202 </para></listitem></varlistentry>
1204 <varlistentry><term><literal>flavor data</literal></term>
1206 The value of the option is the result of evaluating the expression.
1207 </para></listitem></varlistentry>
1212 There are a number of valid uses for calculated options, and there are
1213 also many cases where some other CDL facility would be more
1214 appropriate. Valid uses of calculated options include the following:
1219 On some target hardware a particular feature may be user-configurable,
1220 while on other targets it is fixed. For example some processors can
1221 operate in either big-endian or little-endian mode, while other
1222 processors do not provide any choice. It is possible to have an
1223 option <literal>CYGARC_BIGENDIAN</literal> which is calculated in
1224 some architectural HAL packages but user-modifiable in others.
1228 Calculated options can provide an alternative way for one package to
1229 affect the behavior of another one. Suppose a package may provide two
1230 possible implementations, a preferred one involving self-modifying
1231 code and a slower alternative. If the system involves a ROM bootstrap
1232 then the slower alternative must be used, but it would be
1233 inappropriate to modify the startup option in every HAL to impose
1234 constraints on this package. Instead it is possible to have a
1235 calculated option whose value is
1236 <literal>{ CYG_HAL_STARTUP == "ROM" }</literal>,
1237 and which has appropriate consequences. Arguably this is a spurious
1238 example, and it should be a user choice whether or not to use
1239 self-modifying code with a &default-value; based on
1240 <literal>CYG_HAL_STARTUP</literal>, but that is for the component
1245 Sometimes it should be possible to perform a particular test at
1246 compile-time, for example by using a C preprocessor
1247 <literal>#if</literal> construct. However the preprocessor has only
1248 limited functionality, for example it cannot perform string
1249 comparisons. CDL expressions are more powerful.
1253 Occasionally a particular sub-expression may occur multiple times in
1254 a CDL script. If the sub-expression is sufficiently complex then it
1255 may be worthwhile to have a calculated option whose value is the
1256 sub-expression, and then reference that calculated option in the
1263 Alternatives to using calculated options include the following:
1268 CDL <link linkend="language.interface">interfaces</link> are a form of
1269 calculated option intended as an abstraction mechanism. An interface
1270 can be used to express the concept of <emphasis>any
1271 scheduler</emphasis>, as opposed to a specific one such as the bitmap scheduler.
1275 If a calculated option would serve only to add additional information
1276 to a configuration header file, it may be possible to achieve the same
1277 effect using a <link linkend="ref.define-proc">&define-proc</link>
1278 property or one of the other properties related to header file
1286 If the first entry in a &calculated; expression is a negative
1287 number, for example <literal>calculated -1</literal> then this
1288 can be misinterpreted as an option instead of as part of the
1289 expression. Currently the &calculated; property does not take any
1290 options, but this may change in future. Option processing halts at the
1291 sequence <literal>--</literal>, so the desired value can be expressed
1293 <literal>calculated -- -1</literal>
1299 Some of the CDL scripts in current &eCos; releases make excessive use
1300 of calculated options. This is partly because the recommended
1301 alternatives were not always available at the time the scripts were
1302 written. It is also partly because there is still some missing
1303 functionality, for example &define-proc; properties cannot yet access
1304 the configuration data so it may be necessary to use &calculated;
1305 properties to access the data and perform the desired manipulation via
1306 a &CDL; expression. New scripts should use calculated options only in
1307 accordance with the guidelines.
1313 For options with the booldata flavor the current CDL syntax does not
1314 allow the enabled flag and the value to be calculated separately.
1315 Functionality to permit this may be added in a future release.
1321 It has been suggested that having options which are not
1322 user-modifiable is potentially confusing, and that a top-level
1323 <literal>cdl_constant</literal> command should be added to the
1324 language instead of or in addition to the &calculated; property. Such
1325 a change is under consideration. However because the value of a
1326 calculated option can depend on other options, it is not necessarily
1333 <refsect1><title>Example</title>
1334 <programlisting width=72>
1335 # A constant on some target hardware, perhaps user-modifiable on other
1337 cdl_option CYGNUM_HAL_RTC_PERIOD {
1338 display "Real-time clock period"
1345 <refsect1><title>See Also</title>
1347 Properties <link linkend="ref.default-value">&default-value;</link>,
1348 <link linkend="ref.flavor">&flavor;</link> and
1349 <link linkend="ref.legal-values">&legal-values;</link>,
1356 <!-- {{{ compile -->
1358 <refentry id="ref.compile">
1360 <refentrytitle>&compile;</refentrytitle>
1364 <refname>Property &compile;</refname>
1365 <refpurpose>List the source files that should be built if this option
1366 is active and enabled.</refpurpose>
1371 cdl_option <name> {
1372 compile [-library=libxxx.a] <list of files>
1378 <refsect1><title>Description</title>
1380 The &compile; property allows component developers to specify source
1381 files which should be compiled and added to one of the target
1382 libraries. Usually each source file will end up the library
1383 <filename>libtarget.a</filename>. It is possible for component writers
1384 to specify an alternative library for an entire package using the
1385 <link linkend="ref.library">&library;</link> property. Alternatively
1386 the desired library can be specified on the &compile; line itself. For
1387 example, to add a particular source file to the
1388 <filename>libextras.a</filename> library the following could be used:
1390 <programlisting width=72>
1391 cdl_package CYGPKG_IO_SERIAL {
1393 compile -library=libextras.a common/tty.c
1397 Details of the build process including such issues as compiler flags
1398 and the order in which things happen can be found in
1399 <xref linkend="build">.
1402 &compile; properties can occur in any of &cdl-option;,
1403 &cdl-component;, &cdl-package; or &cdl-interface;. A &compile;
1404 property has effect if and only if the entity that contains it is
1405 active and enabled. Typically the body of a &cdl-package; will define
1406 any source files that need to be built irrespective of individual
1407 options, and each &cdl-component;, &cdl-option;, and &cdl-interface;
1408 will define source files that are more specific. A single &compile;
1409 property can list any number of source files, all destined for the
1410 same library. A &cdl-option; or other entity can contain multiple
1411 &compile; properties, each of which can specify a different library.
1412 It is possible for a given source file to be specified in &compile;
1413 properties for several different options, in which case the source
1414 file will get built if any of these options are active and enabled.
1417 If the package follows the <link linkend="package.hierarchy">directory
1418 layout conventions</link> then the configuration tools will search for
1419 the specified source files first in the
1420 <filename class="directory">src</filename> subdirectory of the
1421 package, then relative to the package directory itself.
1426 A shortcoming of the current specification of &compile; properties is
1427 that there is no easy way to specify source files that should be built
1428 unless an option is enabled. It would sometimes be useful to be able
1429 to say: “if option <literal>A</literal> is enabled then compile
1430 file <filename>x.c</filename>, otherwise compile file
1431 <filename>y.c</filename>. There are two simple ways of achieving this:
1435 Always compile <filename>y.c</filename>, typically by listing it in
1436 the body of the &cdl-package;, but use
1437 <literal>#ifndef A</literal> to produce an empty object file if
1438 option <literal>A</literal> is not enabled. This has the big
1439 disadvantage that the file always gets compiled and hence for some
1440 configurations builds will take longer than necessary.
1443 Use a &calculated; option whose value is <literal>!A</literal>, and
1444 have a <literal>compile y.c</literal> property in its body. This
1445 has the big disadvantage of adding another calculated option to the
1450 It is likely that this will be resolved in the future, possibly by
1451 using some sort of expression as the argument to a &compile; property.
1457 Currently it is not possible to control the priority of a &compile;
1458 property, in other words the order in which a file gets compiled
1459 relative to other build steps. This functionality might prove useful
1460 for complicated packages and should be added.
1465 <refsect1><title>Example</title>
1466 <programlisting width=72>
1467 cdl_package CYGPKG_INFRA {
1468 display "Infrastructure"
1469 include_dir cyg/infra
1471 Common types and useful macros.
1472 Tracing and assertion facilities.
1473 Package startup options."
1475 compile startup.cxx prestart.cxx pkgstart.cxx userstart.cxx \
1476 dummyxxmain.cxx memcpy.c memset.c delete.cxx \
1482 <refsect1><title>See Also</title>
1484 Properties <link linkend="ref.make">make</link>,
1485 <link linkend="ref.make-object">make_object</link> and
1486 <link linkend="ref.library">library</link>.
1493 <!-- {{{ default_value -->
1495 <refentry id="ref.default-value">
1497 <refentrytitle>&default-value;</refentrytitle>
1501 <refname>Property &default-value;</refname>
1502 <refpurpose>Provide a default value for this option using a CDL expression.</refpurpose>
1507 cdl_option <name> {
1508 default_value <expression>
1514 <refsect1><title>Description</title>
1516 The &default-value; property allows the initial value of a
1517 configuration option to depend on other configuration options. The
1518 arguments to the property should be a &CDL; expression, see
1519 <xref linkend="language.expression"> for the syntactic details.
1520 In many cases a simple constant value will suffice, for example:
1522 <programlisting width=72>
1523 cdl_component CYGPKG_KERNEL_EXCEPTIONS {
1527 cdl_option CYGSEM_KERNEL_EXCEPTIONS_DECODE {
1534 However it is also possible for an option's default value to depend on
1535 other options. For example the common HAL package provides some
1536 support functions that are needed by the &eCos; kernel, but are
1537 unlikely to be useful if the kernel is not being used. This
1538 relationship can be expressed using:
1540 <programlisting width=72>
1541 cdl_option CYGFUN_HAL_COMMON_KERNEL_SUPPORT {
1543 default_value CYGPKG_KERNEL
1547 If the kernel is loaded then this HAL option is automatically enabled,
1548 although the user can still disable it explicitly should this prove
1549 necessary. If the kernel is not loaded then the option is disabled,
1550 although it can still be enabled by the user if desired.
1551 &default-value; expressions can be more complicated than this if
1552 appropriate, and provide a very powerful facility for component
1553 writers who want their code to “just do the right thing”
1554 in a wide variety of configurations.
1557 The &CDL; configuration system evaluates the &default-value;
1558 expression when the current package is loaded and whenever there is a
1559 change to any other option referenced in the expression. The result
1560 depends on the option's flavor:
1563 <variablelist TermLength=16>
1565 <varlistentry><term><literal>flavor none</literal></term>
1567 Options with this flavor have no value, so the &default-value;
1568 property is not applicable.
1569 </para></listitem></varlistentry>
1571 <varlistentry><term><literal>flavor bool</literal></term>
1573 If the expression evaluates to a non-zero result the option is
1574 enabled by default, otherwise it is disabled.
1575 </para></listitem></varlistentry>
1577 <varlistentry><term><literal>flavor booldata</literal></term>
1579 If the result of evaluating the expression is zero then the option is
1580 disabled, otherwise the option is enabled and its value is the result.
1581 </para></listitem></varlistentry>
1583 <varlistentry><term><literal>flavor data</literal></term>
1585 The default value of the option is the result of evaluating the
1587 </para></listitem></varlistentry>
1592 A &cdl-option; or other entity can have at most one &default-value;
1593 property, and it is illegal to have both a &calculated; and a
1594 &default-value; property in one body. If an option does not have
1595 either a &default-value; or a &calculated; property and it does not
1596 have the flavor <literal>none</literal> then the configuration tools
1597 will assume a default value expression of <literal>0</literal>.
1600 On occasion it is useful to have a configuration option
1601 <literal>A</literal> which has both a &requires; constraint on some
1602 other option <literal>B</literal> and a &default-value; expression of
1603 <literal>B</literal>. If option <literal>B</literal> is not enabled
1604 then <literal>A</literal> will also be disabled by default and no
1605 conflict arises. If <literal>B</literal> is enabled then
1606 <literal>A</literal> also becomes enabled and again no conflict
1607 arises. If a user attempts to enable <literal>B</literal> but not
1608 <literal>A</literal> then there will be a conflict. Users should be
1609 able to deduce that the two options are closely interlinked and should
1610 not be manipulated independently except in very unusual circumstances.
1615 If the first entry in a &default-value; expression is a negative
1616 number, for example <literal>default_value -1</literal> then this
1617 can be misinterpreted as an option instead of as part of the
1618 expression. Currently the &default-value; property does not take any
1619 options, but this may change in future. Option processing halts at the
1620 sequence <literal>--</literal>, so the desired value can be expressed
1622 <literal>default_value -- -1</literal>
1628 In many cases it would be useful to calculate default values using
1629 some global preferences, for example:
1631 <programlisting width=72>
1632 cdl_option CYGIMP_LIBC_STRING_PREFER_SMALL_TO_FAST {
1634 default_value CYGGLO_CODESIZE > CYGGLO_SPEED
1638 Such global preference options do not yet exist, but are likely to be
1639 added in a future version.
1645 For options with the booldata flavor the current syntax does not allow
1646 the default values of the enabled flag and the value to be controlled
1647 separately. Functionality to permit this may be added in a future
1654 <refsect1><title>Example</title>
1655 <programlisting width=72>
1656 cdl_option CYGDBG_HAL_DEBUG_GDB_THREAD_SUPPORT {
1657 display "Include GDB multi-threading debug support"
1658 requires CYGDBG_KERNEL_DEBUG_GDB_THREAD_SUPPORT
1659 default_value CYGDBG_KERNEL_DEBUG_GDB_THREAD_SUPPORT
1661 This option enables some extra HAL code which is needed
1662 to support multi-threaded source level debugging."
1667 <refsect1><title>See Also</title>
1669 Properties <link linkend="ref.calculated">&calculated;</link>,
1670 <link linkend="ref.flavor">&flavor;</link> and
1671 <link linkend="ref.legal-values">&legal-values;</link>.
1680 <refentry id="ref.define">
1682 <refentrytitle>&define;</refentrytitle>
1686 <refname>Property &define;</refname>
1687 <refpurpose>Specify additional <literal>#define</literal> symbols that
1688 should go into the owning package's configuration header file.</refpurpose>
1693 cdl_option <name> {
1694 define [-file=<filename>] [-format=<format>] <symbol>
1700 <refsect1><title>Description</title>
1702 Normally the configuration system generates a single
1703 <literal>#define</literal> for each option that is active and enabled,
1704 with the defined symbol being the name of the option. These
1705 <literal>#define's</literal> go to the package's own configuration
1706 header file, for example <filename class="HeaderFile">pkgconf/kernel.h</filename>
1707 for kernel configuration options. For the majority of options this is
1708 sufficient. Sometimes it is useful to have more control over which
1709 <literal>#define's</literal> get generated.
1712 The &define; property can be used to generate an addition
1713 <literal>#define</literal> if the option is both active and enabled,
1716 <programlisting width=72>
1717 cdl_option CYGNUM_LIBC_STDIO_FOPEN_MAX {
1723 If this option is given the value 40 then the following
1724 <literal>#define's</literal> will be generated in the configuration
1725 header <filename class="HeaderFile">pkgconf/libc.h</filename>:
1728 #define CYGNUM_LIBC_STDIO_FOPEN_MAX 40
1729 #define FOPEN_MAX 40
1732 The default <literal>#define</literal> can be suppressed if desired
1733 using the &no-define; property. This is useful if the symbol should
1735 <filename class="HeaderFile">pkgconf/system.h</filename> and not in
1736 the package's own configuration header file. The value that will be
1737 used for this <literal>#define</literal> is the same as for the
1738 default one, and depends on the option's flavor as follows:
1741 <variablelist TermLength=16>
1743 <varlistentry><term><literal>flavor none</literal></term>
1745 Options with this flavor are always enabled and have no value, so the
1746 constant <literal>1</literal> will be used.
1747 </para></listitem></varlistentry>
1749 <varlistentry><term><literal>flavor bool</literal></term>
1751 If the option is disabled then no <literal>#define</literal> will be
1752 generated. Otherwise the constant <literal>1</literal> will be used.
1753 </para></listitem></varlistentry>
1755 <varlistentry><term><literal>flavor booldata</literal></term>
1757 If the option is disabled then no <literal>#define</literal> will be
1758 generated. Otherwise the option's current value will be used.
1759 </para></listitem></varlistentry>
1761 <varlistentry><term><literal>flavor data</literal></term>
1763 The option's current value will be used.
1764 </para></listitem></varlistentry>
1769 For active options with the <literal>data</literal> flavor, and for
1770 active and enabled options with the <literal>booldata</literal>
1771 flavor, either one or two <literal>#define's</literal> will be
1772 generated. These take the following forms:
1774 <programlisting width=72>
1775 #define <symbol> <value>
1776 #define <symbol>_<value>
1779 For the first <literal>#define</literal> it is possible to control the
1780 format used for the value using a
1781 <literal>-format=<format></literal> option. For example, the
1782 following can be used to output some configuration data as a C string:
1784 <programlisting width=72>
1785 cdl_option <name> {
1787 define -format="\\\"%s\\\"" <symbol>
1791 The implementation of this facility involves concatenating the
1792 Tcl command <literal>format</literal>, the format string, and the
1793 string representation of the option's value, and evaluating this in a
1794 Tcl interpreter. Therefore the format string will be processed twice
1795 by a Tcl parser, and appropriate care has to be taken with quoting.
1798 The second <literal>#define</literal> will be generated only if is a
1799 valid C preprocessor macro symbol. By default the symbols generated by
1800 &define; properties will end up in the package's own configuration
1801 header file. The <literal>-file</literal> option can be used to
1802 specify an alternative destination. At the time of writing the only
1803 valid alternative definition is <literal>-file=system.h</literal>,
1804 which will send the output to the global configuration header file
1805 <filename class="HeaderFile">pkgconf/system.h</filename>.
1809 Care has to be taken with the <literal>-format</literal> option.
1810 Because the Tcl interpreter's <literal>format</literal> command is
1811 used, this property is subject to any problems with the implementation
1812 of this in the Tcl library. Generally there should be no problems with
1813 string data or with integers up to 32 bits, but there may well be
1814 problems if 64-bit data is involved. This issue may be addressed in a
1820 <refsect1><title>Example</title>
1821 <programlisting width=72>
1822 cdl_component CYG_HAL_STARTUP {
1823 display "Startup type"
1825 legal_values {"RAM" "ROM" }
1826 default_value {"RAM"}
1828 define -file=system.h CYG_HAL_STARTUP
1834 <refsect1><title>See Also</title>
1836 Properties <link linkend="ref.define-format">&define-format;</link>,
1837 <link linkend="ref.define-header">&define-header;</link>,
1838 <link linkend="ref.define-proc">&define-proc;</link>,
1839 <link linkend="ref.if-define">&if-define;</link> and
1840 <link linkend="ref.no-define">&no-define;</link>.
1847 <!-- {{{ define_format -->
1849 <refentry id="ref.define-format">
1851 <refentrytitle>&define-format;</refentrytitle>
1855 <refname>Property &define-format;</refname>
1856 <refpurpose>Control how an option's value will appear in the
1857 configuration header file.</refpurpose>
1862 cdl_option <name> {
1863 define_format <format string>
1869 <refsect1><title>Description</title>
1871 For active options with the <literal>data</literal> flavor, and for
1872 active and enabled options with the <literal>booldata</literal>
1873 flavor, the configuration tools will normally generate two
1874 <literal>#define's</literal> in the package's configuration header
1875 file. These take the following forms:
1877 <programlisting width=72>
1878 #define <name> <value>
1879 #define <name>_<value>
1882 The &define-format; property can be used to control exactly what
1883 appears as the value for the first of these
1884 <literal>#define's</literal>. For example, the following can be used
1885 to output some configuration data as a C string:
1887 <programlisting width=72>
1888 cdl_option <name> {
1890 define -format="\\\"%s\\\"" <symbol>
1894 The implementation of &define-format; involves concatenating the Tcl
1895 command <literal>format</literal>, the format string, and the string
1896 representation of the option's value, and evaluating this in a Tcl
1897 interpreter. Therefore the format string will be processed twice by a
1898 Tcl parser, and appropriate care has to be taken with quoting.
1901 The second <literal>#define</literal> will be generated only if is a
1902 valid C preprocessor macro symbol, and is not affected by the
1903 &define-format; property. Also, the property is only relevant for
1904 options with the <literal>data</literal> or
1905 <literal>booldata</literal> flavor, and cannot be used in
1906 conjunction with the &no-define; property since it makes no sense to
1907 specify the format if no <literal>#define</literal> is generated.
1911 Because the Tcl interpreter's <literal>format</literal> command is
1912 used, this property is subject to any problems with the implementation
1913 of this in the Tcl library. Generally there should be no problems with
1914 string data or with integers up to 32 bits, but there may well be
1915 problems if 64-bit data is involved. This issue may be addressed in a
1922 <refsect1><title>Example</title>
1923 <programlisting width=72>
1924 cdl_option CYGNUM_UITRON_VER_ID {
1925 display "OS identification"
1927 legal_values 0 to 0xFFFF
1929 define_format "0x%04x"
1931 This value is returned in the 'id'
1932 field of the T_VER structure in
1933 response to a get_ver() system call."
1938 <refsect1><title>See Also</title>
1940 Properties <link linkend="ref.define">&define;</link>,
1941 <link linkend="ref.define-header">&define-header;</link>,
1942 <link linkend="ref.define-proc">&define-proc;</link>,
1943 <link linkend="ref.if-define">&if-define;</link> and
1944 <link linkend="ref.no-define">&no-define;</link>.
1951 <!-- {{{ define_header -->
1953 <refentry id="ref.define-header">
1955 <refentrytitle>&define-header;</refentrytitle>
1959 <refname>Property &define-header;</refname>
1960 <refpurpose>Specify the configuration header file that
1961 will be generated for a given package.</refpurpose>
1966 cdl_package <name> {
1967 define_header <file name>
1973 <refsect1><title>Description</title>
1975 When the configuration tools generate a build tree, one of the steps
1976 is to output each package's configuration data to a header file. For
1977 example the kernel's configuration data gets output to
1978 <filename class="HeaderFile">pkgconf/kernel.h</filename>. This allows
1979 each package's source code to <literal>#include</literal> the
1980 appropriate header file and adapt to the choices made by the user.
1983 By default the configuration tools will synthesize a file name from
1984 the package name. This involves removing any prefix such as
1985 <literal>CYGPKG_</literal>, up to and including the first underscore,
1986 and then converting the remainder of the name to lower case. In some
1987 cases it may be desirable to use a different header file, for example
1988 an existing package may have been ported to &eCos; and the source code
1989 may already <literal>#include</literal> a particular file for
1990 configuration data. In such cases a &define-header; property can be
1991 used to specify an alternative filename.
1994 The &define-header; property can only be used in the body of a
1995 &cdl-package; command. It applies to a package as a whole and cannot
1996 be used at a finer grain. The name specified in a &define-header;
1997 property will always be interpreted as relative to the
1998 <filename class="Directory">include/pkgconf</filename> sub-directory
1999 of the install tree.
2003 For hardware-specific packages such as device drivers and HAL
2004 packages, the current scheme of generating a configuration header file
2005 name based on the package name may be abandoned. Instead all hardware
2006 packages would send their configuration data to a single header file,
2007 <filename class="HeaderFile">pkgconf/hardware.h</filename>. This would
2008 make it easier for code to obtain details of the current hardware, but
2009 obviously there are compatibility issues. For now it is recommended
2010 that all hardware packages specify their configuration header file
2016 <refsect1><title>Example</title>
2017 <programlisting width=72>
2018 cdl_package CYGPKG_HAL_ARM {
2019 display "ARM architecture"
2023 define_header hal_arm.h
2029 <refsect1><title>See Also</title>
2031 Properties <link linkend="ref.define">&define;</link>,
2032 <link linkend="ref.define-format">&define-format;</link>,
2033 <link linkend="ref.define-proc">&define-proc;</link>,
2034 <link linkend="ref.if-define">&if-define;</link>,
2035 <link linkend="ref.no-define">&no-define;</link> and
2036 <link linkend="ref.hardware">&hardware;</link>,
2043 <!-- {{{ define_proc -->
2045 <refentry id="ref.define-proc">
2047 <refentrytitle>&define-proc;</refentrytitle>
2051 <refname>Property &define-proc;</refname>
2052 <refpurpose>Use a fragment of Tcl code to output additional data to
2053 configuration header files.</refpurpose>
2058 cdl_option <name> {
2059 define_proc <Tcl script>
2065 <refsect1><title>Description</title>
2067 For most configuration options it is sufficient to have an entry in
2068 the configuration header file of the form:
2070 <programlisting width=72>
2071 #define <name> <value>
2074 In some cases it is desirable to perform some more complicated
2075 processing when generating a configuration header file. There are a
2076 number of CDL properties for this, including &define-format; and
2077 &if-define;. The most flexible is &define-proc;: this allows the
2078 component writer to specify a Tcl script that gets invoked whenever
2079 the configuration system generates the header file for the owning
2080 package. The script can output anything to the header file, for
2081 example it could generate a C data structure based on various
2082 configuration values.
2085 At the point that the &define-proc; script is invoked there will be
2086 two channels to open files, accessible via Tcl variables:
2087 <literal>cdl_header</literal> is a channel to the current package's
2088 own header file for example
2089 <filename class="HeaderFile">pkgconf/kernel.h</filename>;
2090 <literal>cdl_system_header</literal> is a channel to the global
2092 <filename class="Headerfile">pkgconf/system.h</filename>. A typical
2093 &define-proc; script will use the <literal>puts</literal> command to
2094 output data to one of these channels.
2097 &define-proc; properties only take effect if the current option is
2098 active and enabled. The default behavior of the configuration system
2099 for an option with the <literal>bool</literal> flavor corresponds to
2100 the following &define-proc;:
2102 <programlisting width=72>
2106 puts $cdl_header "#define XXX 1"
2112 In the current implementation it is not possible for a &define-proc;
2113 property to examine the current values of various configuration
2114 options and adapt accordingly. This is a major limitation, and will be
2115 addressed in future versions of the configuration tools.
2121 <refsect1><title>Example</title>
2122 <programlisting width=90>
2123 cdl_package CYGPKG_HAL_ARM_PID {
2124 display "ARM PID evaluation board"
2125 parent CYGPKG_HAL_ARM
2126 define_header hal_arm_pid.h
2131 puts $::cdl_system_header "#define CYGBLD_HAL_TARGET_H <pkgconf/hal_arm.h>"
2132 puts $::cdl_system_header "#define CYGBLD_HAL_PLATFORM_H <pkgconf/hal_arm_pid.h>"
2133 puts $::cdl_header ""
2134 puts $::cdl_header "#define HAL_PLATFORM_CPU \"ARM 7TDMI\""
2135 puts $::cdl_header "#define HAL_PLATFORM_BOARD \"PID\""
2136 puts $::cdl_header "#define HAL_PLATFORM_EXTRA \"\""
2137 puts $::cdl_header ""
2144 <refsect1><title>See Also</title>
2146 Properties <link linkend="ref.define">&define;</link>,
2147 <link linkend="ref.define-format">&define-format;</link>,
2148 <link linkend="ref.define-header">&define-header;</link>,
2149 <link linkend="ref.if-define">&if-define;</link> and
2150 <link linkend="ref.no-define">&no-define;</link>.
2157 <!-- {{{ description -->
2159 <refentry id="ref.description">
2161 <refentrytitle>&description;</refentrytitle>
2165 <refname>Property &description;</refname>
2166 <refpurpose>Provide a textual description for an option.</refpurpose>
2171 cdl_option <name> {
2172 description <text>
2178 <refsect1><title>Description</title>
2180 Users can only be expected to manipulate configuration options
2181 sensibly if they are given sufficient information about these options.
2182 There are three properties which serve to explain an option in plain
2183 text: the &display; property gives a textual alias for an option,
2184 which is usually more comprehensible than something like
2185 <literal>CYGPKG_LIBC_TIME_ZONES</literal>; the &description; property
2186 gives a longer description, typically a paragraph or so; the &doc;
2187 property specifies the location of additional on-line documentation
2188 related to a configuration option. In the context of a graphical tool
2189 the &display; string will be the primary way for users to identify
2190 configuration options; the &description; paragraph will be visible
2191 whenever the option is selected; the on-line documentation will only
2192 be accessed when the user explicitly requests it.
2195 At present there is no way of providing any sort of formatting mark-up
2196 in a description. It is possible that future versions of the
2197 configuration tools will provide some control over the way the
2198 description text gets rendered.
2202 <refsect1><title>Example</title>
2203 <programlisting width=72>
2204 cdl_option CYGDBG_INFRA_DEBUG_TRACE_MESSAGE {
2205 display "Use trace text"
2208 All trace calls within eCos contain a text message
2209 which should give some information about the circumstances.
2210 These text messages will end up being embedded in the
2211 application image and hence there is a significant penalty
2212 in terms of image size.
2213 It is possible to suppress the use of these messages by
2214 disabling this option.
2215 This results in smaller code size, but there is less
2216 human-readable information available in the trace output,
2217 possibly only filenames and line numbers."
2222 <refsect1><title>See Also</title>
2224 Properties <link linkend="ref.display">&display;</link> and
2225 <link linkend="ref.doc">&doc;</link>.
2232 <!-- {{{ display -->
2234 <refentry id="ref.display">
2236 <refentrytitle>&display;</refentrytitle>
2240 <refname>Property &display;</refname>
2241 <refpurpose>Provide a short string describing this option.</refpurpose>
2246 cdl_option <name> {
2247 display <string>
2253 <refsect1><title>Description</title>
2255 Users can only be expected to manipulate configuration options
2256 sensibly if they are given sufficient information about these options.
2257 There are three properties which serve to explain an option in plain
2258 text: the &display; property gives a textual alias for an option,
2259 which is usually more comprehensible than something like
2260 <literal>CYGPKG_LIBC_TIME_ZONES</literal>; the &description; property
2261 gives a longer description, typically a paragraph or so; the &doc;
2262 property specifies the location of additional on-line documentation
2263 related to a configuration option. In the context of a graphical tool
2264 the &display; string will be the primary way for users to identify
2265 configuration options; the &description; paragraph will be visible
2266 whenever the option is selected; the on-line documentation will only
2267 be accessed when the user explicitly requests it.
2271 <refsect1><title>Example</title>
2272 <programlisting width=72>
2273 cdl_option CYGNUM_KERNEL_SYNCH_MBOX_QUEUE_SIZE {
2274 display "Message box queue size"
2276 legal_values 1 to 65535
2279 This configuration option controls the number of messages
2280 that can be queued in a message box before a non-blocking
2281 put() operation will fail or a blocking put() operation will
2282 block. The cost in memory is one pointer per message box for
2283 each possible message."
2288 <refsect1><title>See Also</title>
2290 Properties <link linkend="ref.description">&description;</link> and
2291 <link linkend="ref.doc">&doc;</link>.
2300 <refentry id="ref.doc">
2302 <refentrytitle>&doc;</refentrytitle>
2306 <refname>Property &doc;</refname>
2307 <refpurpose>The location of online-documentation for a configuration option.</refpurpose>
2312 cdl_option <name> {
2319 <refsect1><title>Description</title>
2321 Users can only be expected to manipulate configuration options
2322 sensibly if they are given sufficient information about these options.
2323 There are three properties which serve to explain an option in plain
2324 text: the &display; property gives a textual alias for an option,
2325 which is usually more comprehensible than something like
2326 <literal>CYGPKG_LIBC_TIME_ZONES</literal>; the &description; property
2327 gives a longer description, typically a paragraph or so; the &doc;
2328 property specifies the location of additional on-line documentation
2329 related to a configuration option. In the context of a graphical tool
2330 the &display; string will be the primary way for users to identify
2331 configuration options; the &description; paragraph will be visible
2332 whenever the option is selected; the on-line documentation will only
2333 be accessed when the user explicitly requests it.
2336 The documentation may be an absolute URL, but more generally the
2337 on-line documentation will be shipped with the package and can be
2338 accessed via a relative URL. If the package follows the <link
2339 linkend="package.hierarchy">directory layout conventions</link> then
2340 the configuration tools will search for the specified html file
2341 first in the <filename class="directory">doc</filename> subdirectory
2342 of the package, then relative to the package directory itself. The URL
2343 may contain a <literal>#</literal> character to specify an anchor
2348 At the time of writing the &eCos; packages in the standard
2349 distribution do not conform to the directory layout conventions when
2350 it comes to the documentation. Instead of organizing the documentation
2351 on a per-package basis and placing it in the corresponding
2352 <filename class="directory">doc</filename> sub-directories, all the
2353 documentation is kept in a central location. This should get addressed
2354 in a future release of the system. Third party component writers
2355 should follow the layout conventions.
2360 <refsect1><title>Example</title>
2361 <programlisting width=72>
2362 cdl_package CYGPKG_KERNEL {
2363 display "eCos kernel"
2364 doc ref/ecos-ref.4.html
2365 include_dir cyg/kernel
2367 This package contains the core functionality of the eCos
2368 kernel. It relies on functionality provided by various HAL
2369 packages and by the eCos infrastructure. In turn the eCos
2370 kernel provides support for other packages such as the device
2371 drivers and the uITRON compatibility layer."
2377 <refsect1><title>See Also</title>
2379 Properties <link linkend="ref.description">&description;</link> and
2380 <link linkend="ref.display">&display;</link>.
2389 <refentry id="ref.flavor">
2391 <refentrytitle>&flavor;</refentrytitle>
2395 <refname>Property &flavor;</refname>
2396 <refpurpose>Specify the nature of a configuration option.</refpurpose>
2401 cdl_option <name> {
2402 flavor <flavor>
2408 <refsect1><title>Description</title>
2410 The state of a &CDL; configuration option is a somewhat complicated
2411 concept. This state determines what happens when a build tree is
2412 generated: it controls what files get built and what
2413 <literal>#define's</literal> end up in configuration header files. The
2414 state also controls the values used during expression evaluation. The
2419 An option may or may not be loaded into the current configuration.
2420 However it is still possible for packages to reference options which
2421 are not loaded in a &requires; constraint or other expression. If an
2422 option is not loaded then it will have no direct effect on the build
2423 process, and <literal>0</literal> will be used for expression
2428 Even if an option is loaded it may still be inactive. Usually this is
2429 controlled by the option's location in the configuration hierarchy. If
2430 an option's parent is active and enabled then the option will normally
2431 be active. If the parent is either inactive or disabled then the
2432 option will be inactive. For example, if kernel timeslicing is diabled
2433 then the option <literal>CYGNUM_KERNEL_SCHED_TIMESLICE_TICKS</literal>
2434 is irrelevant and must have no effect. The &active-if; property can be
2435 used to specify additional constraints. If an option is inactive then
2436 it will have no direct effect on the build process, in other words it
2437 will not cause any files to get built or <literal>#define's</literal>
2438 to be generated. For the purposes of expression evaluation an inactive
2439 option has a value of <literal>0</literal>.
2443 An option may be enabled or disabled. Most options are boolean in
2444 nature, for example a particular function may get inlined or it may
2445 involve a full procedure call. If an option is disabled then it has no
2446 direct effect on the build process, and for the purposes of expression
2447 evaluation it has a value of 0.
2450 An option may also have additional data associated with it, for
2451 example a numerical value used to control the size of an array.
2455 Most options are boolean in nature and do not have any additional
2456 associated data. For some options only the data part makes sense and
2457 users should be unable to manipulate the enabled/disabled part of the
2458 state. For a comparatively small number of options it makes sense to
2459 have the ability to disable that option or to enable it and associate
2460 data as well. Finally, when constructing an option hierarchy it is
2461 occasionally useful to have entities which serve only as placeholders.
2462 The &flavor; property can be used to control all this. There are four
2463 possible values. It should be noted that the active or inactive state
2464 of an option takes priority over the flavor: if an option is inactive
2465 then no <literal>#define's</literal> will be generated and any
2466 build-related properties such as &compile; will be ignored.
2469 <variablelist TermLength=16>
2471 <varlistentry><term>flavor <literal>none</literal></term>
2473 The <literal>none</literal> is intended primarily for placeholder
2474 components in the hierarchy, although it can be used for other
2475 purposes. Options with this flavor are always enabled and do not have
2476 any additional data associated with them, so there is no way for users
2477 to modify the option. For the purposes of expression evaluation an
2478 option with flavor <literal>none</literal> always has the value
2479 <literal>1</literal>. Normal <literal>#define</literal> processing
2480 will take place, so typically a single <literal>#define</literal> will
2481 be generated using the option name and a value of
2482 <literal>1</literal>. Similarly build-related properties such as
2483 &compile; will take effect.
2484 </para></listitem></varlistentry>
2486 <varlistentry><term>flavor <literal>bool</literal></term>
2488 Boolean options can be either enabled or disabled, and there is no
2489 additional data associated with them. If a boolean option is disabled
2490 then no <literal>#define</literal> will be generated and any
2491 build-related properties such as &compile; will be ignored. For the
2492 purposes of expression evaluation a disabled option has the value
2493 <literal>0</literal>. If a boolean option is enabled then normal
2494 <literal>#define</literal> processing will take place, all
2495 build-related properties take effect, and the option's value will be
2496 <literal>1</literal>.
2497 </para></listitem></varlistentry>
2499 <varlistentry><term>flavor <literal>data</literal></term>
2501 Options with this flavor are always enabled, and have some additional
2502 data associated with them which can be edited by the user. This data
2503 can be any sequence of characters, although in practice the
2504 &legal-values; property will often be used to impose constraints. In
2505 appropriate contexts such as expressions the configuration tools will
2506 attempt to interpret the data as integer or floating point numbers.
2507 Since an option with the <literal>data</literal> flavor cannot be
2508 disabled, normal <literal>#define</literal> processing takes place and
2509 the data will be used for the value. Similarly all build-related
2510 properties take effect, and the option's value for the purposes of
2511 expression evaluation is the data.
2512 </para></listitem></varlistentry>
2514 <varlistentry><term>flavor <literal>booldata</literal></term>
2516 This combines the <literal>bool</literal> and <literal>data</literal>
2517 flavors. The option may be enabled or disabled, and in addition the
2518 option has some associated data. If the option is disabled then no
2519 <literal>#define</literal> will be generated, the build-related
2520 properties have no effect, and for the purposes of expression
2521 evaluation the option's value is <literal>0</literal>. If the option
2522 is enabled then a <literal>#define</literal> will be generated using
2523 the data as the value, all build-related properties take effect, and
2524 the option's value for the purposes of expression evaluation is the
2525 data. If <literal>0</literal> is legal data then it is not possible to
2526 distinguish this case from the option being disabled or inactive.
2527 </para></listitem></varlistentry>
2532 Options and components have the <literal>bool</literal> flavor by
2533 default, but this can be changed as desired. Packages always have the
2534 <literal>booldata</literal> flavor, and this cannot be changed.
2535 Interfaces have the <literal>data</literal> flavor by default, since
2536 the value of an interface is a count of the number of active and
2537 enabled interfaces, but they can be given the <literal>bool</literal>
2538 or <literal>booldata</literal> flavors.
2543 The expression syntax needs to be extended to allow the loaded,
2544 active, enabled and data aspects of an option's state to be examined
2545 individually. This would allow component writers to distinguish
2546 between a disabled <literal>booldata</literal> option and an enabled
2547 one which has a value of <literal>0</literal>. Such an enhancement to
2548 the expression syntax may also prove useful in other circumstances.
2554 <refsect1><title>Example</title>
2555 <programlisting width=72>
2557 cdl_component CYGPKG_LIBM_COMPATIBILITY {
2559 cdl_component CYGNUM_LIBM_COMPATIBILITY {
2563 cdl_option CYGNUM_LIBM_COMPAT_DEFAULT {
2572 cdl_component CYGPKG_LIBM_TRACE {
2579 <refsect1><title>See Also</title>
2581 Properties <link linkend="ref.calculated">&calculated;</link>,
2582 <link linkend="ref.default-value">&default-value;</link> and
2583 <link linkend="ref.legal-values">&legal-values;</link>,
2590 <!-- {{{ hardware -->
2592 <refentry id="ref.hardware">
2594 <refentrytitle>&hardware;</refentrytitle>
2598 <refname>Property &hardware;</refname>
2599 <refpurpose>Specify that a package is tied to specific hardware.</refpurpose>
2604 cdl_option <name> {
2605 active_if <condition>
2611 <refsect1><title>Description</title>
2613 Some packages such as device drivers and HAL packages are
2614 hardware-specific, and generally it makes no sense to add such
2615 packages to a configuration unless the corresponding hardware is
2616 present on your target system. Typically hardware package selection
2617 happens automatically when you select your target. The &hardware;
2618 property can be used in the body of a &cdl-package; command to
2619 indicate that the package is hardware-specific.
2624 At the time of writing the &hardware; property is largely ignored by
2625 the configuration tools, but this may change in future. Amongst other
2626 possible changes, for hardware-specific packages such as device
2627 drivers and HAL packages, the current scheme of generating a
2628 configuration header file name based purely on the package name may be
2629 abandoned. Instead all hardware packages would send their
2630 configuration data to a single header file, <filename
2631 class="HeaderFile">pkgconf/hardware.h</filename>. This would make it
2632 easier for code to obtain details of the current hardware, but
2633 obviously there are compatibility issues. For now it is recommended
2634 that all hardware packages specify their configuration header file
2640 <refsect1><title>Example</title>
2641 <programlisting width=72>
2642 cdl_package CYGPKG_HAL_ARM {
2643 display "ARM architecture"
2647 define_header hal_arm.h
2653 <refsect1><title>See Also</title>
2655 Property <link linkend="ref.define-header">&define-header;</link>, and
2656 command <link linkend="ref.cdl-package">&cdl-package;</link>.
2663 <!-- {{{ if_define -->
2665 <refentry id="ref.if-define">
2667 <refentrytitle>&if-define;</refentrytitle>
2671 <refname>Property &if-define;</refname>
2672 <refpurpose>Output a common preprocessor construct to a configuration
2673 header file.</refpurpose>
2678 cdl_option <name> {
2679 if_define [-file=<filename>] <symbol1> <symbol2>
2685 <refsect1><title>Description</title>
2687 The purpose of the &if-define; property is best explained by an
2688 example. Suppose you want finer-grained control over assertions, say
2689 on a per-package or even a per-file basis rather than globally. The
2690 assertion macros can be defined by an exported header file in an
2691 infrastructure package, using code like the following:
2693 <programlisting width=72>
2694 #ifdef CYGDBG_USE_ASSERTS
2695 # define CYG_ASSERT( _bool_, _msg_ ) \
2697 if ( ! ( _bool_ ) ) \
2698 CYG_ASSERT_DOCALL( _msg_ ); \
2701 # define CYG_ASSERT( _bool_, _msg_ ) CYG_EMPTY_STATEMENT
2705 Assuming this header file is <literal>#include'd</literal> directly or
2706 indirectly by any code which may need to be built with assertions
2707 enabled, the challenge is now to control whether or not
2708 <varname>CYGDBG_USE_ASSERTS</varname> is defined for any given source
2709 file. This is the purpose of the &if-define; property:
2711 <programlisting width=72>
2712 cdl_option CYGDBG_KERNEL_USE_ASSERTS {
2714 if_define CYGSRC_KERNEL CYGDBG_USE_ASSERTS
2715 requires CYGDBG_INFRA_ASSERTION_SUPPORT
2719 If this option is active and enabled then the kernel's configuration
2720 header file would end up containing the following:
2722 <programlisting width=72>
2723 #ifdef CYGSRC_KERNEL
2724 # define CYGDBG_USE_ASSERTS 1
2728 Kernel source code can now begin with the following construct:
2730 <programlisting width=72>
2731 #define CYGSRC_KERNEL 1
2732 #include <pkgconf/kernel.h>
2733 #include <cyg/infra/cyg_ass.h>
2736 The configuration option only affects kernel source code, assuming
2737 nothing else <literal>#define's</literal> the symbol
2738 <varname>CYGSRC_KERNEL</varname>. If the per-package assertion option
2739 is disabled then <varname>CYGDBG_USE_ASSERTS</varname> will not get
2740 defined. If the option is enabled then
2741 <varname>CYGDBG_USE_ASSERTS</varname> will get defined and assertions
2742 will be enabled for the kernel sources. It is possible to use the same
2743 mechanism for other facilities such as tracing, and to apply it at a
2744 finer grain such as individual source files by having multiple options
2745 with &if-define; properties and multiple symbols such as
2746 <varname>CYGSRC_KERNEL_SCHED_BITMAP_CXX</varname>.
2749 The &if-define; property takes two arguments, both of which must be
2750 valid C preprocessor symbols. If the current option is active and
2751 enabled then three lines will be output to the configuration header
2754 <programlisting width=72>
2755 #ifdef <symbol1>
2756 # define <symbol2>
2760 If the option is inactive or disabled then these lines will not be
2761 output. By default the current package's configuration header file
2762 will be used, but it is possible to specify an alternative destination
2763 using a <literal>-file</literal> option. At present the only
2764 legitimate alternative destination is <literal>system.h</literal>, the
2765 global configuration header. &if-define; processing happens in
2766 addition to, not instead of, the normal <literal>#define</literal>
2767 processing or the handling of other header-file related properties.
2771 The infrastructure in the current &eCos; release does not yet work
2772 this way. In future it may do so, and the intention is that suitable
2773 configuration options get generated semi-automatically by the
2774 configuration system rather than having to be defined explicitly.
2779 As an alternative to changing the configuration, updating the build
2780 tree, and so on, it is possible to enable assertions by editing a
2781 source file directly, for example:
2783 <programlisting width=72>
2784 #define CYGSRC_KERNEL 1
2785 #define CYGDBG_USE_ASSERTS 1
2786 #include <pkgconf/kernel.h>
2787 #include <cyg/infra/cyg_ass.h>
2790 The assertion header file does not care whether
2791 <varname>CYGDBG_USE_ASSERTS</varname> is <literal>#define'd</literal>
2792 via a configuration option or by explicit code. This technique can be
2793 useful to component writers when debugging their source code, although
2794 care has to be taken to remove any such <literal>#define's</literal>
2801 <refsect1><title>Example</title>
2802 <programlisting width=72>
2803 cdl_option CYGDBG_KERNEL_USE_ASSERTS {
2804 display "Assertions in the kernel package"
2806 if_define CYGSRC_KERNEL CYGDBG_USE_ASSERTS
2807 requires CYGDBG_INFRA_ASSERTION_SUPPORT
2812 <refsect1><title>See Also</title>
2814 Properties <link linkend="ref.define">&define;</link>,
2815 <link linkend="ref.define-format">&define-format;</link>,
2816 <link linkend="ref.define-header">&define-header;</link>,
2817 <link linkend="ref.define-proc">&define-proc;</link> and
2818 <link linkend="ref.no-define">&no-define;</link>.
2825 <!-- {{{ implements -->
2827 <refentry id="ref.implements">
2829 <refentrytitle>&implements;</refentrytitle>
2833 <refname>Property &implements;</refname>
2834 <refpurpose>Enabling this option provides one instance of a more
2835 general interface.</refpurpose>
2840 cdl_option <name> {
2841 implements <interface>
2847 <refsect1><title>Description</title>
2849 The &CDL; interface concept provides an abstraction mechanism that can
2850 be useful in many different circumstances. Essentially an interface is
2851 a calculated option whose value is the number of active and enabled
2852 options which implement that interface. For example the interface
2853 <varname>CYGINT_KERNEL_SCHEDULER</varname> has a value corresponding
2854 to the number of schedulers in the system, typically just one.
2857 The &implements; property takes a single argument, which should be the
2858 name of an interface. This interface may be defined in the same
2859 package as the implementor or in some other package. In the latter
2860 case it may sometimes be appropriate for the implementor or the
2861 implementor's package to have a &requires; property for the package
2862 containing the interface. An option may contain multiple &implements;
2863 properties. It is possible for an option to implement a given
2864 interface multiple times, and on occasion this is actually useful.
2868 <refsect1><title>Example</title>
2869 <programlisting width=72>
2870 cdl_option CYGSEM_KERNEL_SCHED_MLQUEUE {
2871 display "Multi-level queue scheduler"
2873 implements CYGINT_KERNEL_SCHEDULER
2879 <refsect1><title>See Also</title>
2881 Command <link linkend="ref.cdl-interface">&cdl-interface;</link>.
2888 <!-- {{{ include_dir -->
2890 <refentry id="ref.include-dir">
2892 <refentrytitle>&include-dir;</refentrytitle>
2896 <refname>Property &include-dir;</refname>
2897 <refpurpose>Specify the desired location of a package's exported
2898 header files in the install tree.</refpurpose>
2903 cdl_package <name> {
2904 include_dir <sub-directory>
2910 <refsect1><title>Description</title>
2912 Most packages export one or more header files defining their public
2913 interface. For example the C library exports header files such as
2914 <filename class="HeaderFile">stdio.h</filename> and
2915 <filename class="HeaderFile">ctype.h</filename>.
2916 If the package follows the <link linkend="package.hierarchy">directory
2917 layout conventions</link> then the exported header files will normally
2918 be found in the package's
2919 <filename class="directory">include</filename> sub-directory.
2920 Alternatively the &include-files; property can be used to specify
2921 which header files should be exported.
2924 By default a package's exported header files will be copied to
2925 the <filename class="directory">include</filename> sub-directory of
2926 the install tree. This is correct for packages like the C library
2927 because that is the correct location for files such as
2928 <filename class="HeaderFile">stdio.h</filename>. However to reduce the
2929 probability of name clashes it is desirable for packages to use
2930 different sub-directories, for example infrastructure header files get
2931 copied to <filename class="directory">include/cyg/infra</filename>
2932 rather than to the top-level
2933 <filename class="directory">include</filename> directory itself.
2936 It would be possible to replicate these sub-directories in each
2937 package's source tree, such that the infrastructure header file
2939 <filename class="directory">include/cyg/infra</filename> in the source
2940 tree as well as in the install tree. This would make things more
2941 difficult for the package developers. Instead it is possible to
2942 specify the desired install tree sub-directory using an &include-dir;
2943 property, for example <literal>include_dir cyg/infra</literal>.
2946 The &include-dir; property can only be used in the body of a
2947 &cdl-package; command, since it applies to all of the header files
2948 exported by a package, and only one &include-dir; property can be
2949 used. If there is no &include-dir; property then exported header files
2950 will end up in the top-level <filename class="directory">include</filename>
2951 directory of the install tree.
2955 <refsect1><title>Example</title>
2956 <programlisting width=72>
2957 cdl_package CYGPKG_INFRA {
2958 display "Infrastructure"
2959 include_dir cyg/infra
2961 Common types and useful macros.
2962 Tracing and assertion facilities.
2963 Package startup options."
2969 <refsect1><title>See Also</title>
2971 Property <link linkend="ref.include-files">&include-files;</link>, and
2972 command <link linkend="ref.cdl-package">&cdl-package;</link>.
2979 <!-- {{{ include_files -->
2981 <refentry id="ref.include-files">
2983 <refentrytitle>&include-files;</refentrytitle>
2987 <refname>Property &include-files;</refname>
2988 <refpurpose>List the header files that are exported by a package.</refpurpose>
2993 cdl_package <name> {
2994 include_files <file1> …
3000 <refsect1><title>Description</title>
3002 Most packages export one or more header files defining their public
3003 interface. For example the C library exports header files such as
3004 <filename class="HeaderFile">stdio.h</filename> and
3005 <filename class="HeaderFile">ctype.h</filename>.
3006 If the package follows the <link linkend="package.hierarchy">directory
3007 layout conventions</link> then the exported header files will normally
3008 be found in the package's
3009 <filename class="directory">include</filename> sub-directory. For
3010 packages which do not follow these conventions, typically simple ones
3011 for which a complicated sub-directory hierarchy is undesirable, there
3012 has to be an alternative way of specifying which header file or files
3013 define the public interface. The &include-files; property provides
3017 By default, if a package does not have an
3018 <filename class="directory">include</filename> subdirectory and it
3019 does not have an &include-files; property then all files with a suffix
3020 of <literal>.h</literal>, <literal>.hxx</literal>,
3021 <literal>.inl</literal> or <literal>.inc</literal> will be treated as
3022 public header files. However some of these may be private files
3023 containing implementation details. If there is an
3024 &include-files; property then only the files listed in that property
3028 If a package should not export any header files but does contain
3029 private implementation headers, an &include-files; property with no
3030 arguments should be used.
3034 <refsect1><title>Example</title>
3035 <programlisting width=72>
3036 cdl_package <SOME_PACKAGE> {
3038 include_dir <some directory>
3039 include_files interface.h
3042 cdl_package <ANOTHER_PACKAGE> {
3049 <refsect1><title>See Also</title>
3051 Property <link linkend="ref.include-dir">&include-dir;</link>, and
3052 command <link linkend="ref.cdl-package">&cdl-package;</link>.
3059 <!-- {{{ legal_values -->
3061 <refentry id="ref.legal-values">
3063 <refentrytitle>&legal-values;</refentrytitle>
3067 <refname>Property &legal-values;</refname>
3068 <refpurpose>Impose constraints on the possible values for an option.</refpurpose>
3073 cdl_option <name> {
3074 legal_values <list expression>
3080 <refsect1><title>Description</title>
3082 Options with the <literal>data</literal> or
3083 <literal>booldata</literal> flavors can have an arbitrary sequence of
3084 characters as their data. In nearly all cases some restrictions have
3085 to be imposed, for example the data should correspond to a number
3086 within a certain range, or it should be one of a small number of
3087 constants. The &legal-values; property can be used to impose such
3088 constraints. The arguments to the property should be a &CDL; list
3089 expression, see <xref linkend="language.list-expression"> for the
3090 syntactic details. Common examples include:
3092 <programlisting width=72>
3093 legal_values 0 to 0x7fff
3094 legal_values 9600 19200 38400
3095 legal_values { "RAM" "ROM" }
3098 The &legal-values; property can only be used for options with the
3099 <literal>data</literal> or <literal>booldata</literal> flavors, since
3100 it makes little sense to further constrain the legal values of a
3101 boolean option. An option can have at most one &legal-values;
3107 If the first entry in a &legal-values; list expression is a negative
3109 <literal>legal_values -1 to 1</literal> then this can
3110 be misinterpreted as an option instead of as part of the expression.
3111 Currently the &legal-values; property does not take any options, but
3112 this may change in future. Option processing halts at the sequence
3113 <literal>--</literal>, so the desired range can be expressed safely
3114 using <literal>legal_values -- -1 to 1</literal>
3120 Architectural HAL packages should provide constants which can be used
3121 in &legal-values; list expressions. For example it should be possible
3122 to specify a numeric range such as
3123 <literal>0 to CYGARC_MAXINT</literal>, rather than
3124 hard-wiring numbers such as <literal>0x7fffffff</literal> which may
3125 not be valid on all targets. Current HAL packages do not define such
3132 The &legal-values; property is restricted mainly to numerical ranges
3133 and simple enumerations, and cannot cope with more complicated data
3134 items. Future versions of the configuration system will provide
3135 additional data validation facilities, for example a
3136 <literal>check_proc</literal> property which specifies a Tcl script
3137 that can be used to perform the validation.
3142 <refsect1><title>Example</title>
3143 <programlisting width=72>
3144 cdl_option CYGNUM_LIBC_TIME_STD_DEFAULT_OFFSET {
3145 display "Default Standard Time offset"
3147 legal_values -- -90000 to 90000
3150 This option controls the offset from UTC in
3151 seconds when in local Standard Time. This
3152 value can be positive or negative. It
3153 can also be set at run time using the
3154 cyg_libc_time_setzoneoffsets() function."
3159 <refsect1><title>See Also</title>
3161 Properties <link linkend="ref.calculated">&calculated;</link>,
3162 <link linkend="ref.default-value">&default-value;</link>, and
3163 <link linkend="ref.flavor">&flavor;</link>.
3170 <!-- {{{ library -->
3172 <refentry id="ref.library">
3174 <refentrytitle>&library;</refentrytitle>
3178 <refname>Property &library;</refname>
3179 <refpurpose>Specify which library should contain the object files
3180 generated by building this package.</refpurpose>
3185 cdl_package <name> {
3186 library <library name>
3192 <refsect1><title>Description</title>
3194 By default all object files that get built for all packages end up in
3195 a single library, <filename>libtarget.a</filename>. This makes things
3196 easier for the typical application developer because it is only
3197 necessary to link with a single library, rather than with separate
3198 libraries for each package. It is possible to specify an alternative
3199 library for specific files as an option to the &compile; and
3200 &make-object; properties, and there is one library <link
3201 linkend="build"><filename>libextras.a</filename></link> which serves a
3202 specific purpose in the build system. The &library; property allows an
3203 alternative library to be specified for all the object files that will
3204 be generated for a given package.
3207 The use of the &library; property should be avoided, since it makes
3208 things more difficult for application developers. The property is
3209 intended only for special cases, for example if there are legal
3210 objections to mingling object files from different packages in a
3211 single library. It could also be used to work around name clash
3212 problems if two packages happen to define an exported symbol with the
3213 same name, but any attempt to use multiple libraries in this way is
3214 error-prone and should be avoided.
3217 The &library; property takes a single argument, the name of a library,
3218 which should follow the standard naming convention of
3219 <literal>lib<something>.a</literal>. A &library; property can
3220 only occur in the body of a &cdl-package; command and applies to all
3221 object files generated for that package (except where explicitly
3222 overwritten with a <literal>-library=</literal> option to one of the
3223 build-related properties). A &cdl-package; body can contain at most
3224 one &library; property.
3228 <refsect1><title>Example</title>
3229 <programlisting width=72>
3230 cdl_package <SOME_PACKAGE> {
3232 library libSomePackage.a
3237 <refsect1><title>See Also</title>
3239 Properties <link linkend="ref.compile">&compile;</link>,
3240 <link linkend="ref.make">&make;</link>, and
3241 <link linkend="ref.make-object">&make-object;</link>,
3242 command <link linkend="ref.cdl-package">&cdl-package;</link>.
3251 <refentry id="ref.make">
3253 <refentrytitle>&make;</refentrytitle>
3257 <refname>Property &make;</refname>
3258 <refpurpose>Define an additional custom build step associated with an
3259 option, resulting in a target that should not go directly into a library.</refpurpose>
3264 cdl_option <name> {
3265 make [-priority=<pri>] {
3266 <custom build step>
3273 <refsect1><title>Description</title>
3275 When building an &eCos; configuration the primary target is a single
3276 library, <filename>libtarget.a</filename>. In some cases it is
3277 necessary to build some additional targets. For example architectural
3278 HAL packages typically build a linker script and some start-up code.
3279 Such additional targets can be specified by a &make; property. Any
3280 option can have one or more &make; properties, although typically such
3281 properties only occur in the body of a &cdl-package; command.
3284 The &make; property takes a single argument, which resembles a
3285 makefile rule: it consists of a target, a list of dependencies, and
3286 one or more commands that should be executed. However the argument is
3287 not a makefile fragment, and custom build steps may get executed in
3288 build environments that do not involve make. For full details of
3289 custom build steps see <xref linkend="build.custom">.
3293 The exact syntax and limitations of custom build steps have not yet
3294 been finalized, and are subject to change in future versions of the
3295 configuration tools.
3299 The &make; property takes an optional priority argument indicating the
3300 order in which build steps take place. This priority complements the
3301 dependency list, and avoids problems with packages needing to know
3302 details of custom build steps in other packages (which may change
3303 between releases). The defined order is:
3305 <variablelist termlength=12>
3307 <varlistentry><term>Priority 0</term>
3309 The header files exported by the current set of packages are copied
3310 to the appropriate places in the
3311 <filename class="directory">include</filename> subdirectory of the
3312 install tree. Any unnecessary copies are avoided, to prevent rebuilds
3313 of package and application source modules caused by header file dependencies.
3316 A possible future enhancement of the build system may result in the
3317 build and install trees being updated automatically if there has been
3318 a change to the <filename>ecos.ecc</filename> configuration savefile.
3319 </para></note></listitem>
3322 <varlistentry><term>Priority 100</term>
3324 All files specified in &compile; properties will get built, producing
3325 the corresponding object files. In addition any custom build steps
3326 defined by &make-object; properties get executed, unless there is
3327 a <literal>-priority=</literal> option.
3331 <varlistentry><term>Priority 200</term>
3333 The libraries now get built using the appropriate object files.
3337 <varlistentry><term>Priority 300</term>
3339 Any custom build steps specified by &make; properties now get
3340 executed, unless the priority for a particular build step is changed
3347 For example, if a custom build step needs to take place before any of
3348 the normal source files get compiled then it should be given a
3349 priority somewhere between 0 and 100. If a custom build step involves
3350 post-processing an object file prior to its incorporation into a
3351 library then a priority between 100 and 200 should be used.
3356 <refsect1><title>Example</title>
3357 <programlisting width=88>
3358 cdl_package CYGPKG_HAL_MN10300_AM33 {
3359 display "MN10300 AM33 variant"
3360 parent CYGPKG_HAL_MN10300
3361 implements CYGINT_HAL_MN10300_VARIANT
3364 define_header hal_mn10300_am33.h
3366 The MN10300 AM33 variant HAL package provides generic
3367 support for this processor architecture. It is also
3368 necessary to select a specific target platform HAL
3372 <PREFIX>/lib/target.ld: <PACKAGE>/src/mn10300_am33.ld
3373 $(CC) -E -P -Wp,-MD,target.tmp -DEXTRAS=1 -xc $(INCLUDE_PATH) $(CFLAGS) -o $@ $<
3374 @echo $@ ": \\" > $(notdir $@).deps
3375 @tail +2 target.tmp >> $(notdir $@).deps
3376 @echo >> $(notdir $@).deps
3383 <refsect1><title>See Also</title>
3385 Properties <link linkend="ref.compile">compile</link>,
3386 <link linkend="ref.make-object">make_object</link> and
3387 <link linkend="ref.library">library</link>.
3394 <!-- {{{ make_object -->
3396 <refentry id="ref.make-object">
3398 <refentrytitle>&make-object;</refentrytitle>
3402 <refname>Property &make-object;</refname>
3403 <refpurpose>Define a custom build step, resulting in an object file
3404 that should go into a library.</refpurpose>
3409 cdl_option <name> {
3410 make_object [-library=<library>] [-priority=<pri>] {
3411 <custom build step>
3418 <refsect1><title>Description</title>
3420 When building an &eCos; configuration the primary target is a single
3421 library, <filename>libtarget.a</filename>. Most of the object files
3422 which go into this library will be generated as a result of &compile;
3423 properties. Occasionally it may be necessary to have special build
3424 steps for a given object file, and this can be achieved with a
3425 &make-object; property. The use of this property should be avoided
3426 whenever possible because it greatly increases the risk of portability
3427 problems, both on the host side because of possible problems with the
3428 tools, and on the target side because a custom build step may not
3429 allow adequately for the wide variety of architectures supported by
3433 The &make-object; property takes a single argument, which resembles a
3434 makefile rule: it consists of a target, a list of dependencies, and
3435 one or more commands that should be executed. The target should be an
3436 object file. However the &make-object; argument is not a makefile
3437 fragment, and custom build steps may get executed in build
3438 environments that do not involve make. For full details of custom
3439 build steps see <xref linkend="build.custom">.
3443 The exact syntax and limitations of custom build steps have not yet
3444 been finalized, and may change in future versions of the
3445 configuration tools.
3449 The &make-object; property takes an optional library argument. If no
3450 library is specified then the default library for the current package
3451 will be used, which will be <filename>libtarget.a</filename> unless
3452 the &cdl-package; command contains a &library; property.
3455 The &make-object; property also takes an optional priority argument
3456 indicating the order in which build steps take place. This priority
3457 complements the dependency list, and avoids problems with packages
3458 needing to know details of custom build steps in other packages (which
3459 may change between releases). The defined order is:
3461 <variablelist termlength=12>
3463 <varlistentry><term>Priority 0</term>
3465 The header files exported by the current set of packages are copied
3466 to the appropriate places in the
3467 <filename class="directory">include</filename> subdirectory of the
3468 install tree. Any unnecessary copies are avoided, to prevent rebuilds
3469 of package and application source modules caused by header file dependencies.
3472 A possible future enhancement of the build system may result in the
3473 build and install trees being updated automatically if there has been
3474 a change to the <filename>ecos.ecc</filename> configuration savefile.
3475 </para></note></listitem>
3478 <varlistentry><term>Priority 100</term>
3480 All files specified in &compile; properties will get built, producing
3481 the corresponding object files. In addition any custom build steps
3482 defined by &make-object; properties get executed, unless there is a
3483 <literal>-priority=</literal> option.
3487 <varlistentry><term>Priority 200</term>
3489 The libraries now get built using the appropriate object files.
3493 <varlistentry><term>Priority 300</term>
3495 Any custom build steps specified by &make; properties now get
3496 executed, unless the priority for a particular build step is changed
3503 For example, if a custom build step needs to take place before any of
3504 the normal source files get compiled then it should be given a
3505 priority somewhere between 0 and 100. If a custom build step involves
3506 post-processing an object file prior to its incorporation into a
3507 library then a priority between 100 and 200 should be used. It is not
3508 sensible to have a priority above 200, since that would imply building
3509 an additional object file for a library that has already been created.
3513 <refsect1><title>Example</title>
3514 <programlisting width=72>
3520 $(CC) $(CFLAGS) -o $@ y.tab.c
3526 <refsect1><title>See Also</title>
3528 Properties <link linkend="ref.compile">compile</link>,
3529 <link linkend="ref.make">make</link> and
3530 <link linkend="ref.library">library</link>.
3537 <!-- {{{ no_define -->
3539 <refentry id="ref.no-define">
3541 <refentrytitle>&no-define;</refentrytitle>
3545 <refname>Property &no-define;</refname>
3546 <refpurpose>Suppress the normal generation of a preprocessor
3547 <literal>#define</literal> symbol in a configuration header file.</refpurpose>
3552 cdl_option <name> {
3559 <refsect1><title>Description</title>
3561 By default all active and enabled properties result in either one or
3562 two <literal>#define'd</literal> symbols in the package's
3563 configuration header file, and this is one of the main ways in which
3564 options can affect packages at build-time. It is possible to suppress
3565 the default <literal>#define's</literal> by specifying a
3566 &no-define; property in the body of an option or other &CDL; entity.
3567 This property takes no arguments and should occur only once in a given
3571 The &no-define; property is frequently used in conjunction with one of
3572 the other header-file related properties such as &define;. If one of
3573 the other properties is used to export the required information to a
3574 configuration header file then often there is little point in
3575 exporting the default <literal>#define</literal> as
3576 well &mdash in fact there could be a name clash. The
3577 &no-define; property can also be useful if the sole purpose of an
3578 option is to affect which files get built, and the default
3579 <literal>#define</literal> would never get tested in any source code.
3580 However in such cases the default <literal>#define</literal> is
3581 mostly harmless and there is little to be gained by suppressing it.
3586 <refsect1><title>Example</title>
3587 <programlisting width=72>
3588 cdl_component CYG_HAL_STARTUP {
3589 display "Startup type"
3591 legal_values { "RAM" "ROM" }
3592 default_value {"RAM"}
3594 define -file system.h CYG_HAL_STARTUP
3600 <refsect1><title>See Also</title>
3602 Properties <link linkend="ref.define">&define;</link>,
3603 <link linkend="ref.define-format">&define-format;</link>,
3604 <link linkend="ref.define-header">&define-header;</link>,
3605 <link linkend="ref.define-proc">&define-proc;</link> and
3606 <link linkend="ref.if-define">&if-define;</link>.
3615 <refentry id="ref.parent">
3617 <refentrytitle>&parent;</refentrytitle>
3621 <refname>Property &parent;</refname>
3622 <refpurpose>Control the location of an option in the configuration hierarchy.</refpurpose>
3627 cdl_option <name> {
3628 parent <component or package>
3634 <refsect1><title>Description</title>
3636 Configuration options live in a hierarchy of packages and components.
3637 By default a given option's position in the hierarchy is a simple
3638 consequence of its position within the CDL scripts. Packages are
3639 generally placed at the top-level of the configuration. Any components
3640 or options that are defined at the same level as the &cdl-package;
3641 command in a package's top-level CDL script are placed immediately
3642 below that package in the hierarchy. Any options or components that
3643 are defined in the body of a &cdl-package; or &cdl-component; command,
3644 or that are read in as a result of processing a component's &script;
3645 property, will be placed immediately below that package or component
3649 In some circumstances it is useful to specify an alternative position
3650 in the hierarchy for a given option. For example it is often
3651 convenient to re-parent device driver packages below
3652 <varname>CYGPKG_IO</varname> in the configuration hierarchy, thus
3653 reducing the number of packages at the top level of the hierarchy and
3654 making navigation easier. The &parent; property can be used to achieve
3658 The &parent; property takes a single argument, which should be the
3659 name of a package or component. The body of a &cdl-option; or other
3660 CDL entity can contain at most one &parent; property.
3663 Although the &parent; property affects an option's position in the
3664 overall hierarchy and hence whether or not that option is active, a
3665 re-parented option still belongs to the package that defines it. By
3666 default any <literal>#define's</literal> will be exported to that
3667 package's configuration header file. Any &compile; properties can only
3668 reference source files present in that package, and it is not directly
3669 possible to cause some file in another package to be built by
3673 As a special case, if an empty string is specified for the parent then
3674 the option is placed at the top of the hierarchy, ahead of any
3675 packages which are not explicitly re-parented in this way. This
3676 facility is useful for configuration options such as global
3677 preferences and default compiler flags.
3682 If an option is re-parented somewhere below another package and that
3683 other package is not actually loaded, the option is an orphan and its
3684 active/inactive state is undefined. In such cases it is a good idea
3685 for the owning package to require the presence of the other one.
3686 Unfortunately this technique does not work if a package as a whole is
3687 reparented below another one that has not been loaded: the package is
3688 orphaned so it may be automatically inactive, and hence any &requires;
3689 properties would have no effect.
3695 <refsect1><title>Example</title>
3696 <programlisting width=72>
3697 cdl_package CYGPKG_HAL_I386 {
3698 display "i386 architecture"
3702 define_header hal_i386.h
3706 cdl_component CYGBLD_GLOBAL_OPTIONS {
3707 display "Global build options"
3714 <refsect1><title>See Also</title>
3716 Property <link linkend="ref.script">&script;</link>,
3717 commands <link linkend="ref.cdl-component">&cdl-component;</link> and
3718 <link linkend="ref.cdl-package">&cdl-package;</link>.
3725 <!-- {{{ requires -->
3727 <refentry id="ref.requires">
3729 <refentrytitle>&requires;</refentrytitle>
3733 <refname>Property &requires;</refname>
3734 <refpurpose>List constraints that the configuration should satisfy if
3735 a given option is active and enabled..</refpurpose>
3740 cdl_option <name> {
3741 requires <goal expression>
3747 <refsect1><title>Description</title>
3749 Configuration options are not independent. For example the C library
3750 can provide thread-safe implementations of certain functions, but only
3751 if the kernel is present, if the kernel provides multi-threading, and
3752 if the kernel options related to per-thread data are enabled. It is
3753 possible to express such constraints using &requires; properties.
3756 The arguments to a &requires; property should constitute a goal
3757 expression, as described in <xref linkend="language.list-expression">.
3758 Most goal expressions are relatively simple because the constraints
3759 being described are simple, but complicated expressions can be used
3760 when necessary. The body of an option or other CDL entity can contain
3761 any number of &requires; constraints. If the option is active and
3762 enabled then all these constraints should be satisfied, and any goal
3763 expressions which evaluate to <literal>0</literal> will result in
3764 conflicts being raised. It is possible for users to ignore such
3765 conflicts and attempt to build the current configuration anyway, but
3766 there is no guarantee that anything will work. If an option is
3767 inactive or disabled then its &requires; constraints will be ignored.
3770 The configuration system contains an inference engine which can
3771 resolve many types of conflicts automatically. For example, if option
3772 <literal>A</literal> is enabled and requires an option
3773 <literal>B</literal> that is currently disabled then the inference
3774 engine may attempt to resolve the conflict by enabling
3775 <literal>B</literal>. However this will not always be possible, for
3776 example there may be other constraints in the configuration which
3777 force <literal>B</literal> to be disabled at present, in which case
3778 user intervention is required.
3782 <refsect1><title>Example</title>
3783 <programlisting width=72>
3784 cdl_component CYGPKG_IO_SERIAL_POWERPC_COGENT_SERIAL_A {
3785 display "Cogent PowerPC serial port A driver"
3788 requires (CYGIMP_KERNEL_INTERRUPTS_CHAIN || \
3789 !CYGPKG_IO_SERIAL_POWERPC_COGENT_SERIAL_B)
3795 <refsect1><title>See Also</title>
3797 Property <link linkend="ref.active-if">&active-if;</link>.
3806 <refentry id="ref.script">
3808 <refentrytitle>&script;</refentrytitle>
3812 <refname>Property &script;</refname>
3813 <refpurpose>Include additional configuration information from another
3814 CDL script.</refpurpose>
3819 cdl_component <name> {
3820 script <filename>
3826 <refsect1><title>Description</title>
3828 It is possible to define all the configuration options and
3829 sub-components for a given package in a single CDL script, either by
3830 nesting them in the appropriate command bodies, by extensive use of
3831 the &parent; property, or by some combination of these two. However
3832 for large packages this is inconvenient and it is better to split the
3833 raw configuration data over several different files. The &script;
3834 property can be used to achieve this. It takes a single filename as
3835 argument. If the package follows the <link
3836 linkend="package.hierarchy">directory layout conventions</link> then
3837 the configuration tools will look for the specified file in the
3838 <filename class="directory">cdl</filename> sub-directory of the
3839 package, otherwise it will look for the file relative to the package's
3840 top-level directory.
3843 The &script; property can only occur in the body of a &cdl-component
3844 command, and only one &script; property per body is allowed.
3848 <refsect1><title>Example</title>
3849 <programlisting width=72>
3850 cdl_component CYGPKG_UITRON_TASKS {
3854 uITRON Tasks are the basic blocks of multi-tasking
3855 in the uITRON world; they are threads or lightweight
3856 processes, sharing the address space and the CPU.
3857 They communicate using the primitives outlined above.
3858 Each has a stack, an entry point (a C or C++ function),
3859 and (where appropriate) a scheduling priority."
3866 <refsect1><title>See Also</title>
3868 Command <link linkend="ref.cdl-component">&cdl-component;</link>,
3869 and property <link linkend="ref.parent">&parent;</link>.