?? build.make.html
字號:
<!-- Copyright (C) 2003 Red Hat, Inc. -->
<!-- This material may be distributed only subject to the terms -->
<!-- and conditions set forth in the Open Publication License, v1.0 -->
<!-- or later (the latest version is presently available at -->
<!-- http://www.opencontent.org/openpub/). -->
<!-- Distribution of the work or derivative of the work in any -->
<!-- standard (paper) book form is prohibited unless prior -->
<!-- permission is obtained from the copyright holder. -->
<HTML
><HEAD
><TITLE
>Building eCos</TITLE
><meta name="MSSmartTagsPreventParsing" content="TRUE">
<META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
"><LINK
REL="HOME"
TITLE="The eCos Component Writer's Guide"
HREF="cdl-guide.html"><LINK
REL="UP"
TITLE="The Build Process"
HREF="build.html"><LINK
REL="PREVIOUS"
TITLE="Configuration Header File Generation"
HREF="build.headers.html"><LINK
REL="NEXT"
TITLE="Building Test Cases"
HREF="build.tests.html"></HEAD
><BODY
CLASS="SECT1"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>The <SPAN
CLASS="APPLICATION"
>eCos</SPAN
> Component Writer's Guide</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="build.headers.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Chapter 4. The Build Process</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="build.tests.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="BUILD.MAKE">Building eCos</H1
><P
>The primary goal of an eCos build is to produce the library
<TT
CLASS="FILENAME"
>libtarget.a</TT
>. A typical <SPAN
CLASS="APPLICATION"
>eCos</SPAN
> build will also
generate a number of other targets: <TT
CLASS="FILENAME"
>extras.o</TT
>,
startup code <TT
CLASS="FILENAME"
>vectors.o</TT
>, and a linker script. Some
packages may cause additional libraries or targets to be generated.
The basic build process involves a number of different phases with
corresponding priorities. There are a number of predefined priorities:</P
><DIV
CLASS="INFORMALTABLE"
><A
NAME="AEN2463"><P
></P
><TABLE
BORDER="1"
CLASS="CALSTABLE"
><THEAD
><TR
><TH
WIDTH="50%"
ALIGN="RIGHT"
VALIGN="TOP"
>Priority</TH
><TH
WIDTH="50%"
ALIGN="LEFT"
VALIGN="TOP"
>Action</TH
></TR
></THEAD
><TBODY
><TR
><TD
WIDTH="50%"
ALIGN="RIGHT"
VALIGN="TOP"
>0</TD
><TD
WIDTH="50%"
ALIGN="LEFT"
VALIGN="TOP"
>Export header files</TD
></TR
><TR
><TD
WIDTH="50%"
ALIGN="RIGHT"
VALIGN="TOP"
>100</TD
><TD
WIDTH="50%"
ALIGN="LEFT"
VALIGN="TOP"
>Process <SPAN
CLASS="PROPERTY"
>compile</SPAN
> properties</TD
></TR
><TR
><TD
WIDTH="50%"
ALIGN="RIGHT"
VALIGN="TOP"
> </TD
><TD
WIDTH="50%"
ALIGN="LEFT"
VALIGN="TOP"
>and most <SPAN
CLASS="PROPERTY"
>make_object</SPAN
> custom build steps</TD
></TR
><TR
><TD
WIDTH="50%"
ALIGN="RIGHT"
VALIGN="TOP"
>200</TD
><TD
WIDTH="50%"
ALIGN="LEFT"
VALIGN="TOP"
>Generate libraries</TD
></TR
><TR
><TD
WIDTH="50%"
ALIGN="RIGHT"
VALIGN="TOP"
>300</TD
><TD
WIDTH="50%"
ALIGN="LEFT"
VALIGN="TOP"
>Process <SPAN
CLASS="PROPERTY"
>make</SPAN
> custom build steps</TD
></TR
></TBODY
></TABLE
><P
></P
></DIV
><P
>Generation of the <TT
CLASS="FILENAME"
>extras.o</TT
> file, the startup code
and the linker script actually happens via <SPAN
CLASS="PROPERTY"
>make</SPAN
> custom build steps,
typically defined in appropriate HAL packages. The component framework
has no special knowledge of these targets.</P
><P
>By default custom build steps for a <SPAN
CLASS="PROPERTY"
>make_object</SPAN
> property happen
during the same phase as most compilations, but this can be changed
using a <TT
CLASS="LITERAL"
>-priority</TT
> option. Similarly custom build
steps for a <SPAN
CLASS="PROPERTY"
>make</SPAN
> property happen at the end of a build, but this can
also be changed with a <TT
CLASS="LITERAL"
>-priority</TT
> option. For
example a priority of 50 can be used to run a custom build step
between the header file export phase and the main compilation phase.
Custom build steps are discussed in more detail below.</P
><P
>Some build systems may run several commands of the same priority in
parallel. For example files listed in <SPAN
CLASS="PROPERTY"
>compile</SPAN
> properties may get
compiled in parallel, concurrently with <SPAN
CLASS="PROPERTY"
>make_object</SPAN
> custom build
steps with default priorities. Since most of the time for an <SPAN
CLASS="APPLICATION"
>eCos</SPAN
>
build involves processing <SPAN
CLASS="PROPERTY"
>compile</SPAN
> properties, this allows builds to
be speeded up on suitable host hardware. All build steps for a given
phase will complete before the next phase is started.</P
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="BUILD.MAKE.UPDATE">Updating the Build Tree</H2
><P
>Some build systems may involve a phase before the header files get
exported, to update the build and install trees automatically when
there has been a change to the configuration savefile
<TT
CLASS="FILENAME"
>ecos.ecc</TT
>. This is useful mainly for application
developers using the command line tools: it would allow users to
create the build tree only once, and after any subsequent
configuration changes the tree would be updated automatically by the
build system. The facility would be analogous to the
<TT
CLASS="LITERAL"
>--enable-maintainer-mode</TT
> option provide by the
<SPAN
CLASS="APPLICATION"
>autoconf</SPAN
> and <SPAN
CLASS="APPLICATION"
>automake</SPAN
> programs. At present no <SPAN
CLASS="APPLICATION"
>eCos</SPAN
>
build system implements this functionality, but it is likely to be
added in a future release.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="BUILD.MAKE.EXPORT">Exporting Public Header Files</H2
><P
>The first compulsory phase involves making sure that there is an up to
date set of header files in the install tree. Each package can contain
some number of header files defining the exported interface.
Applications should only use exported functionality. A package can
also contain some number of private header files which are only of
interest to the implementation, and which should not be visible to
application code. The various packages that go into a particular
configuration can be spread all over the component repository. In
theory it might be possible to make all the exported header files
accessible by having a lengthy <TT
CLASS="LITERAL"
>-I</TT
> header file
search path, but this would be inconvenient both for building eCos and
for building applications. Instead all the relevant header files are
copied to a single location, the <TT
CLASS="FILENAME"
>include</TT
> subdirectory of the install tree.
The process involves the following:</P
><P
></P
><OL
TYPE="1"
><LI
><P
>The install tree, for example <TT
CLASS="FILENAME"
>/usr/local/ecos/install</TT
>, and its <TT
CLASS="FILENAME"
>include</TT
> subdirectory <TT
CLASS="FILENAME"
>/usr/local/ecos/install/include</TT
> will typically be
created when the build tree is generated or updated. At the same time
configuration header files will be written to the <TT
CLASS="FILENAME"
>pkgconf</TT
> subdirectory, for example
<TT
CLASS="FILENAME"
>/usr/local/ecos/include/pkgconf</TT
>, so that
the configuration data is visible to all the packages and to
application code that may wish to examine some of the configuration
options.</P
></LI
><LI
><P
>Each package in the configuration is examined for exported header
files. The exact order in which the packages are processed is not
defined, but should not matter.</P
><P
></P
><OL
TYPE="a"
><LI
><P
>If the package has an <A
HREF="ref.include-files.html"
><SPAN
CLASS="PROPERTY"
>include_files</SPAN
></A
> property then this
lists all the exported header files:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>cdl_package <some_package> {
…
include_files header1.h header2.h
} </PRE
></TD
></TR
></TABLE
><P
>If no arguments are given then the package does not export any header
files.</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>cdl_package <some_package> {
…
include_files
} </PRE
></TD
></TR
></TABLE
><P
>The listed files may be in an <TT
CLASS="FILENAME"
>include</TT
> subdirectory within the package's
hierarchy, or they may be relative to the package's toplevel
directory. The <SPAN
CLASS="PROPERTY"
>include_files</SPAN
> property is intended mainly for very
simple packages. It can also be useful when converting existing code
to an <SPAN
CLASS="APPLICATION"
>eCos</SPAN
> package, to avoid rearranging the sources.</P
></LI
><LI
><P
>If there is no <SPAN
CLASS="PROPERTY"
>include_files</SPAN
> property then the component framework
will look for an <TT
CLASS="FILENAME"
>include</TT
>
subdirectory in the package, as per the layout conventions. All files,
including those in subdirectories, will be treated as exported header
files. For example, the math library package contains files <TT
CLASS="FILENAME"
>include/math.h</TT
> and <TT
CLASS="FILENAME"
>include/sys/ieeefp.h</TT
>, both of which will
be exported to the install tree.</P
></LI
><LI
><P
>As a last resort, if there is neither an <SPAN
CLASS="PROPERTY"
>include_files</SPAN
> property nor
an <TT
CLASS="FILENAME"
>include</TT
> subdirectory, the
component framework will search the package's toplevel directory and
all of its subdirectories for files with one of the following
suffixes: <TT
CLASS="LITERAL"
>.h</TT
>, <TT
CLASS="LITERAL"
>.hxx</TT
>,
<TT
CLASS="LITERAL"
>.inl</TT
> or <TT
CLASS="LITERAL"
>.inc</TT
>. All such files
will be interpreted as exported header files.</P
><P
>This last resort rule could cause confusion for packages which have no
exported header files but which do contain one or more private header
files. For example a typical device driver simply implements an
existing interface rather than define a new one, so it does not need
to export a header file. However it may still have one or more private
header files. Such packages should use an <SPAN
CLASS="PROPERTY"
>include_files</SPAN
> property
with no arguments.</P
></LI
></OL
></LI
><LI
><P
>If the package has one or more exported header files, the next step is
to determine where the files should end up. By default all exported
header files will just end up relative to the install tree's <TT
CLASS="FILENAME"
>include</TT
> subdirectory. For example the
math library's <TT
CLASS="FILENAME"
>math.h</TT
> header
would end up as <TT
CLASS="FILENAME"
>/usr/local/ecos/include/math.h</TT
>,
and the <TT
CLASS="FILENAME"
>sys/ieeefp.h</TT
> header
would end up as
<TT
CLASS="FILENAME"
>/usr/local/ecos/include/sys/ieeefp.h</TT
>. This
behaviour is correct for packages like the C library where the
interface is defined by appropriate standards. For other packages this
behaviour can lead to file name clashes, and the <A
HREF="ref.include-dir.html"
><SPAN
CLASS="PROPERTY"
>include_dir</SPAN
></A
> property should be used
to avoid this:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>cdl_package CYGPKG_KERNEL {
include_dir cyg/kernel
}</PRE
></TD
></TR
></TABLE
><P
>This means that the kernel's exported header file
<TT
CLASS="FILENAME"
>include/kapi.h</TT
> should be copied to
<TT
CLASS="FILENAME"
>/usr/local/ecos/include/cyg/kernel/kapi.h</TT
>, where
it is very unlikely to clash with a header file from some other
package.</P
></LI
><LI
><P
>For typical application developers there will be little or no need for
the installed header files to change after the first build. Changes
will be necessary only if packages are added to or removed from the
configuration. For component writers, the build system should detect
changes to the master copy of the header file source code and update
the installed copies automatically during the next build. The build
system is expected to perform a header file dependency analysis, so
any source files affected should get rebuilt as well.</P
></LI
><LI
><P
>Some build systems may provide additional support for application
developers who want to make minor changes to a package, especially for
debugging purposes. A header file could be copied from the
component repository (which for application developers is assumed to
be a read-only resource) into the build tree and edited there. The
build system would detect a more recent version of such a header file
in the build tree and install it. Care would have to be taken to
recover properly if the modified copy in the build tree is
subsequently removed, in order to revert to the original behaviour.</P
></LI
><LI
><P
>When updating the install tree's <TT
CLASS="FILENAME"
>include</TT
> subdirectory, the build tree may
also perform a clean-up operation. Specifically, it may check for any
files which do not correspond to known exported header files and
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -