language.properties.html

有关ecos2。0介绍了实时嵌入式的结构以及线程调度的实现和内存的管理等

<A
HREF="ref.define.html"
><SPAN
CLASS="PROPERTY"
>define</SPAN
></A
>,
<A
HREF="ref.if-define.html"
><SPAN
CLASS="PROPERTY"
>if_define</SPAN
></A
>, and
<A
HREF="ref.define-proc.html"
><SPAN
CLASS="PROPERTY"
>define_proc</SPAN
></A
>.</P
><P
>By default the component framework will generate a configuration
header file for each package based on the package's name: everything
up to and including the first underscore is discarded, the rest of the
name is lower-cased, and a <TT
CLASS="LITERAL"
>.h</TT
> suffix is appended.
For example the configuration header file for the kernel package
<TT
CLASS="VARNAME"
>CYGPKG_KERNEL</TT
> is <TT
CLASS="FILENAME"
>pkgconf/kernel.h</TT
>. The <SPAN
CLASS="PROPERTY"
>define_header</SPAN
>
property can be used to specify an alternative filename. This applies
to all the components and options within a package, so it can only be
used in the body of a <TT
CLASS="LITERAL"
>cdl_package</TT
> command. For example the following
specifies that the configuration header file for the SPARClite HAL
package is <TT
CLASS="FILENAME"
>pkgconf/hal_sparclite.h</TT
>.</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>cdl_package CYGPKG_HAL_SPARCLITE {
    display "SPARClite architecture"
    parent        CYGPKG_HAL
    hardware
    define_header hal_sparclite.h
    &#8230;
}</PRE
></TD
></TR
></TABLE
><DIV
CLASS="NOTE"
><BLOCKQUOTE
CLASS="NOTE"
><P
><B
>Note: </B
>At present the main use for the <SPAN
CLASS="PROPERTY"
>define_header</SPAN
> property is related 
to hardware packages, see the <A
HREF="ref.hardware.html"
>reference
pages</A
> for more details.</P
></BLOCKQUOTE
></DIV
><P
>The <SPAN
CLASS="PROPERTY"
>no_define</SPAN
> property is used to suppress the generation of the
default <TT
CLASS="LITERAL"
>#define</TT
>. This can be useful if an option's
consequences are all related to the build process or to constraints,
and the option is never actually checked in any source code. It can
also be useful in conjunction with the <SPAN
CLASS="PROPERTY"
>define</SPAN
>, <SPAN
CLASS="PROPERTY"
>if_define</SPAN
> or
<SPAN
CLASS="PROPERTY"
>define_proc</SPAN
> properties. The <SPAN
CLASS="PROPERTY"
>no_define</SPAN
> property does not take any
arguments. </P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>cdl_component CYG_HAL_STARTUP {
    display       "Startup type"
    flavor        data
    legal_values  { "RAM" "ROM" }
    default_value {"RAM"}
    no_define
    define -file system.h CYG_HAL_STARTUP
    &#8230;
}</PRE
></TD
></TR
></TABLE
><P
>This example also illustrates the <SPAN
CLASS="PROPERTY"
>define</SPAN
> property, which can be used
to generate a <TT
CLASS="LITERAL"
>#define</TT
> in addition to the default
one. It takes a single argument, the name of the symbol to be defined.
It also takes options to control the configuration header file in
which the symbol should be defined and the format to be used.</P
><P
>The <SPAN
CLASS="PROPERTY"
>define_format</SPAN
> property can be used to control how the value part
of the default <TT
CLASS="LITERAL"
>#define</TT
> gets formatted. For example
a format string of  <TT
CLASS="LITERAL"
>"0x%04x"</TT
> could be used to
generate a four-digit hexadecimal number. </P
><P
>The <SPAN
CLASS="PROPERTY"
>if_define</SPAN
> property is intended for use primarily to control
assertions, tracing, and similar functionality. It supports a specific
implementation model for these, allowing control at the grain of
packages or even individual source files. The <A
HREF="ref.if-define.html"
>reference pages</A
> provide additional
information.</P
><P
>The <SPAN
CLASS="PROPERTY"
>define_proc</SPAN
> property provides an escape mechanism for those
cases where something special has to happen at configuration header
file generation time. It takes a single argument, a fragment of <SPAN
CLASS="APPLICATION"
>Tcl</SPAN
>
code, which gets executed when the header file is generated. This code
can output arbitrary data to the header file, or perform any other
actions that might be appropriate.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="LANGUAGE.PROPERTIES.BUILD">Controlling what gets Built</H2
><P
>There are six properties which affect the build process:
<A
HREF="ref.compile.html"
><SPAN
CLASS="PROPERTY"
>compile</SPAN
></A
>,
<A
HREF="ref.make.html"
><SPAN
CLASS="PROPERTY"
>make</SPAN
></A
>,
<A
HREF="ref.make-object.html"
><SPAN
CLASS="PROPERTY"
>make_object</SPAN
></A
>,
<A
HREF="ref.library.html"
><SPAN
CLASS="PROPERTY"
>library</SPAN
></A
>,
<A
HREF="ref.include-dir.html"
><SPAN
CLASS="PROPERTY"
>include_dir</SPAN
></A
>, and
<A
HREF="ref.include-files.html"
><SPAN
CLASS="PROPERTY"
>include_files</SPAN
></A
>.
The last three apply to a package as a whole, and can only occur in
the body of a <TT
CLASS="LITERAL"
>cdl_package</TT
> command.</P
><P
>Most of the source files that go into a package should simply be
compiled with the appropriate compiler, selected by the target
architecture, and with the appropriate flags, with an additional set
defined by the target hardware and possible modifications on a
per-package basis. The resulting object files will go into the library
<TT
CLASS="FILENAME"
>libtarget.a</TT
>, which can then be linked against
application code. The <SPAN
CLASS="PROPERTY"
>compile</SPAN
> property is used to list these source
files: </P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>cdl_package CYGPKG_ERROR {
    display       "Common error code support"
    compile       strerror.cxx
    include_dir   cyg/error
    &#8230;
}</PRE
></TD
></TR
></TABLE
><P
>The arguments to the <SPAN
CLASS="PROPERTY"
>compile</SPAN
> property should be one or more source
files. Typically most of the sources will be needed for the package as
a whole, and hence they will be listed in one or more <SPAN
CLASS="PROPERTY"
>compile</SPAN
>
properties in the body of the <TT
CLASS="LITERAL"
>cdl_package</TT
>. Some sources may be
specific to particular configuration options, in other words there is
no point in compiling them unless that option is enabled, in which
case the sources should be listed in a <SPAN
CLASS="PROPERTY"
>compile</SPAN
> property in the
corresponding <TT
CLASS="LITERAL"
>cdl_option</TT
>, <TT
CLASS="LITERAL"
>cdl_component</TT
> or <TT
CLASS="LITERAL"
>cdl_interface</TT
> body.</P
><P
>Some packages may have more complicated build requirements, for
example they may involve a special target such as a linker script
which should not end up in the usual library, or they may involve
special build steps for generating an object file. The <SPAN
CLASS="PROPERTY"
>make</SPAN
> and
<SPAN
CLASS="PROPERTY"
>make_object</SPAN
> properties provide support for such requirements, for
example:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>cdl_package CYGPKG_HAL_MN10300_AM33 {
    display       "MN10300 AM33 variant"
    &#8230;
    make {
        &lt;PREFIX&gt;/lib/target.ld: &lt;PACKAGE&gt;/src/mn10300_am33.ld
        $(CC) -E -P -Wp,-MD,target.tmp -DEXTRAS=1 -xc $(INCLUDE_PATH) \
            $(CFLAGS) -o $@ $&lt;
        @echo $@ ": \\" &gt; $(notdir $@).deps
        @tail +2 target.tmp &gt;&gt; $(notdir $@).deps
        @echo &gt;&gt; $(notdir $@).deps
        @rm target.tmp
    }
}</PRE
></TD
></TR
></TABLE
><P
>For full details of custom build steps and the build process
generally, see <A
HREF="build.html"
>Chapter 4</A
>.</P
><P
>By default all object files go into the library
<TT
CLASS="FILENAME"
>libtarget.a</TT
>. It is possible to override this at
the package level using the <SPAN
CLASS="PROPERTY"
>library</SPAN
> property, but this should be
avoided since it complicates application development: instead of just
linking with a single library for all <SPAN
CLASS="APPLICATION"
>eCos</SPAN
>-related packages, it
suddenly becomes necessary to link with several libraries.</P
><P
>The <SPAN
CLASS="PROPERTY"
>include_dir</SPAN
> and <SPAN
CLASS="PROPERTY"
>include_files</SPAN
> properties relate to a package's
exported header files. By default a package's header files will be
exported to the <TT
CLASS="FILENAME"
>install/include</TT
>
directory. This is the desired behavior for some packages like the C
library, since headers like <TT
CLASS="FILENAME"
>stdio.h</TT
> should exist at that level.
However if all header files were to end up in that directory then
there would be a significant risk of a name clash. Instead it is
better for packages to specify some sub-directory for their exported
header files, for example:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>cdl_package CYGPKG_INFRA {
    display       "Infrastructure"
    include_dir   cyg/infra
    &#8230;
}</PRE
></TD
></TR
></TABLE
><P
>The various header files exported by the infrastructure, for example
<TT
CLASS="FILENAME"
>cyg_ass.h</TT
> and <TT
CLASS="FILENAME"
>cyg_trac.h</TT
> will now end up in the
<TT
CLASS="FILENAME"
>install/include/cyg/infra</TT
>
sub-directory, where a name clash is very unlikely.</P
><P
>For packages which follow the <A
HREF="package.html#PACKAGE.HIERARCHY"
>directory layout conventions</A
> the
component framework will assume that the package's
<TT
CLASS="FILENAME"
>include</TT
> sub-directory contains
all exported header files. If this is not the case, for example
because the package is sufficiently simple that the layout convention
is inappropriate, then the exported header files can be listed
explicitly in an <SPAN
CLASS="PROPERTY"
>include_files</SPAN
> property.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="LANGUAGE.PROPERTIES.MISCELLANEOUS">Miscellaneous Properties</H2
><P
>The <A
HREF="ref.hardware.html"
><SPAN
CLASS="PROPERTY"
>hardware</SPAN
></A
> property is
only relevant to packages. Some packages such as device drivers and
HAL packages are hardware-specific, and generally it makes no sense to
add such packages to a configuration unless the corresponding hardware
is present on your target system. Typically hardware package selection
happens automatically when you select your target. The <SPAN
CLASS="PROPERTY"
>hardware</SPAN
>
property should be used to identify a hardware-specific package, and
does not take any arguments.</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>cdl_package CYGPKG_HAL_MIPS {
    display "MIPS architecture"
    parent        CYGPKG_HAL
    hardware
    include_dir   cyg/hal
    define_header hal_mips.h
    &#8230;
}</PRE
></TD
></TR
></TABLE
><P
>At present the <SPAN
CLASS="PROPERTY"
>hardware</SPAN
> property is largely ignored by the component
framework. This may change in future releases.</P
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="language.commands.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="cdl-guide.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="language.naming.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>CDL Commands</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="language.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Option Naming Convention</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>