OpenCores
URL https://opencores.org/ocsvn/openrisc_me/openrisc_me/trunk

Subversion Repositories openrisc_me

[/] [openrisc/] [trunk/] [rtos/] [ecos-2.0/] [doc/] [html/] [cdl-guide/] [build.html] - Diff between revs 28 and 174

Only display areas with differences | Details | Blame | View Log

Rev 28 Rev 174
<!-- Copyright (C) 2003 Red Hat, Inc.                                -->
<!-- Copyright (C) 2003 Red Hat, Inc.                                -->
<!-- This material may be distributed only subject to the terms      -->
<!-- This material may be distributed only subject to the terms      -->
<!-- and conditions set forth in the Open Publication License, v1.0  -->
<!-- and conditions set forth in the Open Publication License, v1.0  -->
<!-- or later (the latest version is presently available at          -->
<!-- or later (the latest version is presently available at          -->
<!-- http://www.opencontent.org/openpub/).                           -->
<!-- http://www.opencontent.org/openpub/).                           -->
<!-- Distribution of the work or derivative of the work in any       -->
<!-- Distribution of the work or derivative of the work in any       -->
<!-- standard (paper) book form is prohibited unless prior           -->
<!-- standard (paper) book form is prohibited unless prior           -->
<!-- permission is obtained from the copyright holder.               -->
<!-- permission is obtained from the copyright holder.               -->
<HTML
<HTML
><HEAD
><HEAD
><TITLE
><TITLE
>The Build Process</TITLE
>The Build Process</TITLE
><meta name="MSSmartTagsPreventParsing" content="TRUE">
><meta name="MSSmartTagsPreventParsing" content="TRUE">
<META
<META
NAME="GENERATOR"
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
"><LINK
"><LINK
REL="HOME"
REL="HOME"
TITLE="The eCos Component Writer's Guide"
TITLE="The eCos Component Writer's Guide"
HREF="cdl-guide.html"><LINK
HREF="cdl-guide.html"><LINK
REL="PREVIOUS"
REL="PREVIOUS"
TITLE="Updating the ecos.db database"
TITLE="Updating the ecos.db database"
HREF="language.database.html"><LINK
HREF="language.database.html"><LINK
REL="NEXT"
REL="NEXT"
TITLE="Configuration Header File Generation"
TITLE="Configuration Header File Generation"
HREF="build.headers.html"></HEAD
HREF="build.headers.html"></HEAD
><BODY
><BODY
CLASS="CHAPTER"
CLASS="CHAPTER"
BGCOLOR="#FFFFFF"
BGCOLOR="#FFFFFF"
TEXT="#000000"
TEXT="#000000"
LINK="#0000FF"
LINK="#0000FF"
VLINK="#840084"
VLINK="#840084"
ALINK="#0000FF"
ALINK="#0000FF"
><DIV
><DIV
CLASS="NAVHEADER"
CLASS="NAVHEADER"
><TABLE
><TABLE
SUMMARY="Header navigation table"
SUMMARY="Header navigation table"
WIDTH="100%"
WIDTH="100%"
BORDER="0"
BORDER="0"
CELLPADDING="0"
CELLPADDING="0"
CELLSPACING="0"
CELLSPACING="0"
><TR
><TR
><TH
><TH
COLSPAN="3"
COLSPAN="3"
ALIGN="center"
ALIGN="center"
>The <SPAN
>The <SPAN
CLASS="APPLICATION"
CLASS="APPLICATION"
>eCos</SPAN
>eCos</SPAN
> Component Writer's Guide</TH
> Component Writer's Guide</TH
></TR
></TR
><TR
><TR
><TD
><TD
WIDTH="10%"
WIDTH="10%"
ALIGN="left"
ALIGN="left"
VALIGN="bottom"
VALIGN="bottom"
><A
><A
HREF="language.database.html"
HREF="language.database.html"
ACCESSKEY="P"
ACCESSKEY="P"
>Prev</A
>Prev</A
></TD
></TD
><TD
><TD
WIDTH="80%"
WIDTH="80%"
ALIGN="center"
ALIGN="center"
VALIGN="bottom"
VALIGN="bottom"
></TD
></TD
><TD
><TD
WIDTH="10%"
WIDTH="10%"
ALIGN="right"
ALIGN="right"
VALIGN="bottom"
VALIGN="bottom"
><A
><A
HREF="build.headers.html"
HREF="build.headers.html"
ACCESSKEY="N"
ACCESSKEY="N"
>Next</A
>Next</A
></TD
></TD
></TR
></TR
></TABLE
></TABLE
><HR
><HR
ALIGN="LEFT"
ALIGN="LEFT"
WIDTH="100%"></DIV
WIDTH="100%"></DIV
><DIV
><DIV
CLASS="CHAPTER"
CLASS="CHAPTER"
><H1
><H1
><A
><A
NAME="BUILD">Chapter 4. The Build Process</H1
NAME="BUILD">Chapter 4. The Build Process</H1
><DIV
><DIV
CLASS="TOC"
CLASS="TOC"
><DL
><DL
><DT
><DT
><B
><B
>Table of Contents</B
>Table of Contents</B
></DT
></DT
><DT
><DT
><A
><A
HREF="build.html#BUILD.OUTLINE"
HREF="build.html#BUILD.OUTLINE"
>Build Tree Generation</A
>Build Tree Generation</A
></DT
></DT
><DT
><DT
><A
><A
HREF="build.headers.html"
HREF="build.headers.html"
>Configuration Header File Generation</A
>Configuration Header File Generation</A
></DT
></DT
><DT
><DT
><A
><A
HREF="build.make.html"
HREF="build.make.html"
>Building eCos</A
>Building eCos</A
></DT
></DT
><DT
><DT
><A
><A
HREF="build.tests.html"
HREF="build.tests.html"
>Building Test Cases</A
>Building Test Cases</A
></DT
></DT
></DL
></DL
></DIV
></DIV
><P
><P
>Some <SPAN
>Some <SPAN
CLASS="APPLICATION"
CLASS="APPLICATION"
>CDL</SPAN
>CDL</SPAN
> properties describe the consequences of manipulating
> properties describe the consequences of manipulating
configuration options. There are two main types of consequences.
configuration options. There are two main types of consequences.
Typically enabling a configuration option results in one or more
Typically enabling a configuration option results in one or more
<TT
<TT
CLASS="LITERAL"
CLASS="LITERAL"
>#define's</TT
>#define's</TT
> in a configuration header file, and
> in a configuration header file, and
properties that affect this include <SPAN
properties that affect this include <SPAN
CLASS="PROPERTY"
CLASS="PROPERTY"
>define</SPAN
>define</SPAN
>, <SPAN
>, <SPAN
CLASS="PROPERTY"
CLASS="PROPERTY"
>define_proc</SPAN
>define_proc</SPAN
> and
> and
<SPAN
<SPAN
CLASS="PROPERTY"
CLASS="PROPERTY"
>no_define</SPAN
>no_define</SPAN
>. Enabling a configuration option can also affect the build
>. Enabling a configuration option can also affect the build
process, primarily determining which files get built and added to the
process, primarily determining which files get built and added to the
appropriate library. Properties related to the build process include
appropriate library. Properties related to the build process include
<SPAN
<SPAN
CLASS="PROPERTY"
CLASS="PROPERTY"
>compile</SPAN
>compile</SPAN
> and <SPAN
> and <SPAN
CLASS="PROPERTY"
CLASS="PROPERTY"
>make</SPAN
>make</SPAN
>. This chapter describes the whole build process,
>. This chapter describes the whole build process,
including details such as compiler flags and custom build steps.</P
including details such as compiler flags and custom build steps.</P
><P
><P
>Part of the overall design of the <SPAN
>Part of the overall design of the <SPAN
CLASS="APPLICATION"
CLASS="APPLICATION"
>eCos</SPAN
>eCos</SPAN
> component framework is that
> component framework is that
it can interact with a number of different build systems. The most
it can interact with a number of different build systems. The most
obvious of these is <SPAN
obvious of these is <SPAN
CLASS="APPLICATION"
CLASS="APPLICATION"
>GNU
>GNU
make</SPAN
make</SPAN
>:the component framework can generate one or more
>:the component framework can generate one or more
makefiles, and the user can then build the various packages simply by
makefiles, and the user can then build the various packages simply by
invoking <SPAN
invoking <SPAN
CLASS="APPLICATION"
CLASS="APPLICATION"
>make</SPAN
>make</SPAN
>. However it
>. However it
should also be possible to build <SPAN
should also be possible to build <SPAN
CLASS="APPLICATION"
CLASS="APPLICATION"
>eCos</SPAN
>eCos</SPAN
> by other means: the
> by other means: the
component framework can be queried about what is involved in building
component framework can be queried about what is involved in building
a given configuration, and this information can then be fed into the
a given configuration, and this information can then be fed into the
desired build system. Component writers should be aware of this
desired build system. Component writers should be aware of this
possibility. Most packages will not be affected because the <SPAN
possibility. Most packages will not be affected because the <SPAN
CLASS="PROPERTY"
CLASS="PROPERTY"
>compile</SPAN
>compile</SPAN
>
>
property can be used to provide all the required information, but care
property can be used to provide all the required information, but care
has to be taken when writing custom build steps.</P
has to be taken when writing custom build steps.</P
><DIV
><DIV
CLASS="SECT1"
CLASS="SECT1"
><H1
><H1
CLASS="SECT1"
CLASS="SECT1"
><A
><A
NAME="BUILD.OUTLINE">Build Tree Generation</H1
NAME="BUILD.OUTLINE">Build Tree Generation</H1
><P
><P
>It is necessary to create an <SPAN
>It is necessary to create an <SPAN
CLASS="APPLICATION"
CLASS="APPLICATION"
>eCos</SPAN
>eCos</SPAN
> configuration before anything can
> configuration before anything can
be built. With some tools such as the graphical configuration tool
be built. With some tools such as the graphical configuration tool
this configuration will be created in memory, and it is not essential
this configuration will be created in memory, and it is not essential
to produce an <TT
to produce an <TT
CLASS="FILENAME"
CLASS="FILENAME"
>ecos.ecc</TT
>ecos.ecc</TT
> savefile first (although
> savefile first (although
it is still very desirable to generate such a savefile at some point,
it is still very desirable to generate such a savefile at some point,
to allow the configuration to be re-loaded later on). With other tools
to allow the configuration to be re-loaded later on). With other tools
the savefile is generated first, for example using
the savefile is generated first, for example using
<TT
<TT
CLASS="LITERAL"
CLASS="LITERAL"
>ecosconfig&nbsp;new</TT
>ecosconfig&nbsp;new</TT
>, and then a build tree is
>, and then a build tree is
generated using <TT
generated using <TT
CLASS="LITERAL"
CLASS="LITERAL"
>ecosconfig&nbsp;tree</TT
>ecosconfig&nbsp;tree</TT
>. The savefile
>. The savefile
contains all the information needed to recreate a configuration.</P
contains all the information needed to recreate a configuration.</P
><P
><P
>An <SPAN
>An <SPAN
CLASS="APPLICATION"
CLASS="APPLICATION"
>eCos</SPAN
>eCos</SPAN
> build actually involves three separate trees. The component
> build actually involves three separate trees. The component
repository acts as the source tree, and for application developers
repository acts as the source tree, and for application developers
this should be considered a read-only resource. The build tree is
this should be considered a read-only resource. The build tree is
where all intermediate files, especially object files, are created.
where all intermediate files, especially object files, are created.
The install tree is where the main library
The install tree is where the main library
<TT
<TT
CLASS="FILENAME"
CLASS="FILENAME"
>libtarget.a</TT
>libtarget.a</TT
>, the exported header files, and
>, the exported header files, and
similar files end up. Following a successful build it is possible to
similar files end up. Following a successful build it is possible to
take just the install tree and use it for developing an application:
take just the install tree and use it for developing an application:
none of the files in the component repository or the build tree are
none of the files in the component repository or the build tree are
needed for that. The build tree will be needed again only if the user
needed for that. The build tree will be needed again only if the user
changes the configuration. However the install tree does not contain
changes the configuration. However the install tree does not contain
copies of all of the documentation for the various packages, instead
copies of all of the documentation for the various packages, instead
the documentation is kept only in the component repository.</P
the documentation is kept only in the component repository.</P
><P
><P
>By default the build tree, the install tree, and the
>By default the build tree, the install tree, and the
<TT
<TT
CLASS="FILENAME"
CLASS="FILENAME"
>ecos.ecc</TT
>ecos.ecc</TT
> savefile all reside in the same
> savefile all reside in the same
directory tree. This is not a requirement, both the install tree and
directory tree. This is not a requirement, both the install tree and
the savefile can be anywhere in the file system.</P
the savefile can be anywhere in the file system.</P
><P
><P
>It is worth noting that the component framework does not separate the
>It is worth noting that the component framework does not separate the
usual <TT
usual <TT
CLASS="LITERAL"
CLASS="LITERAL"
>make</TT
>make</TT
> and <TT
> and <TT
CLASS="LITERAL"
CLASS="LITERAL"
>make&nbsp;install</TT
>make&nbsp;install</TT
>
>
stages. A build always populates the install tree, and any
stages. A build always populates the install tree, and any
<TT
<TT
CLASS="LITERAL"
CLASS="LITERAL"
>make&nbsp;install</TT
>make&nbsp;install</TT
> step would be redundant.</P
> step would be redundant.</P
><P
><P
>The install tree will always begin with two directories, <TT
>The install tree will always begin with two directories, <TT
CLASS="FILENAME"
CLASS="FILENAME"
>include</TT
>include</TT
> for the exported header files and
> for the exported header files and
<TT
<TT
CLASS="FILENAME"
CLASS="FILENAME"
>lib</TT
>lib</TT
> for the main library
> for the main library
<TT
<TT
CLASS="FILENAME"
CLASS="FILENAME"
>libtarget.a</TT
>libtarget.a</TT
> and other files
> and other files
such as the linker script. In addition there will be a subdirectory
such as the linker script. In addition there will be a subdirectory
<TT
<TT
CLASS="FILENAME"
CLASS="FILENAME"
>include/pkgconf</TT
>include/pkgconf</TT
> containing the
> containing the
configuration header files, which are generated or updated at the same
configuration header files, which are generated or updated at the same
time the build tree is created or updated. More details of header file
time the build tree is created or updated. More details of header file
generation are given below. Additional <TT
generation are given below. Additional <TT
CLASS="FILENAME"
CLASS="FILENAME"
>include</TT
>include</TT
> subdirectories such as <TT
> subdirectories such as <TT
CLASS="FILENAME"
CLASS="FILENAME"
>sys</TT
>sys</TT
> and <TT
> and <TT
CLASS="FILENAME"
CLASS="FILENAME"
>cyg/kernel</TT
>cyg/kernel</TT
> will be created during the
> will be created during the
first build, when each package's exported header files are copied to
first build, when each package's exported header files are copied to
the install tree. The install tree may also end up with additional
the install tree. The install tree may also end up with additional
subdirectories during a build, for example as a result of custom build
subdirectories during a build, for example as a result of custom build
steps. </P
steps. </P
><P
><P
>The component framework does not define the structure of the build
>The component framework does not define the structure of the build
tree, and this may vary between build systems. It can be assumed that
tree, and this may vary between build systems. It can be assumed that
each package in the configuration will have its own directory in the
each package in the configuration will have its own directory in the
build tree, and that this directory will be used for storing the
build tree, and that this directory will be used for storing the
package's object files and as the current directory for any build
package's object files and as the current directory for any build
steps for that package. This avoids problems when custom build steps
steps for that package. This avoids problems when custom build steps
from different packages generate intermediate files which happen to
from different packages generate intermediate files which happen to
have the same name.</P
have the same name.</P
><P
><P
>Some build systems may allow application developers to copy a source
>Some build systems may allow application developers to copy a source
file from the component repository to the build tree and edit the
file from the component repository to the build tree and edit the
copy. This allows users to experiment with small changes, for example
copy. This allows users to experiment with small changes, for example
to add a couple of lines of debugging to a package, without having to
to add a couple of lines of debugging to a package, without having to
modify the master copy in the component repository which could be
modify the master copy in the component repository which could be
shared by several projects or several people. Functionality such as
shared by several projects or several people. Functionality such as
this is transparent to component writers, and it is the responsibility
this is transparent to component writers, and it is the responsibility
of the build system to make sure that the right thing happens.</P
of the build system to make sure that the right thing happens.</P
><DIV
><DIV
CLASS="NOTE"
CLASS="NOTE"
><BLOCKQUOTE
><BLOCKQUOTE
CLASS="NOTE"
CLASS="NOTE"
><P
><P
><B
><B
>Note: </B
>Note: </B
>There are some unresolved issues related to the build tree and install
>There are some unresolved issues related to the build tree and install
tree. Specifically, when updating an existing build or install tree,
tree. Specifically, when updating an existing build or install tree,
what should happen to unexpected files or directories? Suppose the
what should happen to unexpected files or directories? Suppose the
user started with a configuration that included the math library, and
user started with a configuration that included the math library, and
the install tree contains header files <TT
the install tree contains header files <TT
CLASS="FILENAME"
CLASS="FILENAME"
>include/math.h</TT
>include/math.h</TT
> and <TT
> and <TT
CLASS="FILENAME"
CLASS="FILENAME"
>include/sys/ieeefp.h</TT
>include/sys/ieeefp.h</TT
>. The user then removed
>. The user then removed
the math library from the configuration and is updating the build
the math library from the configuration and is updating the build
tree. It is now desirable to remove these header files from the
tree. It is now desirable to remove these header files from the
install tree, so that if any application code still attempts to use
install tree, so that if any application code still attempts to use
the math library this will fail at compile time rather than at link
the math library this will fail at compile time rather than at link
time. There will also be some object files in the existing
time. There will also be some object files in the existing
<TT
<TT
CLASS="LITERAL"
CLASS="LITERAL"
>libtarget.a</TT
>libtarget.a</TT
> library which are no longer
> library which are no longer
appropriate, and there may be other files in the install tree as a
appropriate, and there may be other files in the install tree as a
result of custom build steps. The build tree will still contain a
result of custom build steps. The build tree will still contain a
directory for the math library, which no longer serves any purpose.</P
directory for the math library, which no longer serves any purpose.</P
><P
><P
>However, it is also possible that some of the files in the build tree
>However, it is also possible that some of the files in the build tree
or the install tree were placed there by the user, in which case
or the install tree were placed there by the user, in which case
removing them automatically would be a bad idea.</P
removing them automatically would be a bad idea.</P
><P
><P
>At present the component framework does not keep track of exactly what
>At present the component framework does not keep track of exactly what
should be present in the build and install trees, so it cannot readily
should be present in the build and install trees, so it cannot readily
determine which files or library members are obsolete and can safely
determine which files or library members are obsolete and can safely
be removed, and which ones are unexpected and need to be reported to
be removed, and which ones are unexpected and need to be reported to
the user. This will be addressed in a future release of the system.</P
the user. This will be addressed in a future release of the system.</P
></BLOCKQUOTE
></BLOCKQUOTE
></DIV
></DIV
></DIV
></DIV
></DIV
></DIV
><DIV
><DIV
CLASS="NAVFOOTER"
CLASS="NAVFOOTER"
><HR
><HR
ALIGN="LEFT"
ALIGN="LEFT"
WIDTH="100%"><TABLE
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
SUMMARY="Footer navigation table"
WIDTH="100%"
WIDTH="100%"
BORDER="0"
BORDER="0"
CELLPADDING="0"
CELLPADDING="0"
CELLSPACING="0"
CELLSPACING="0"
><TR
><TR
><TD
><TD
WIDTH="33%"
WIDTH="33%"
ALIGN="left"
ALIGN="left"
VALIGN="top"
VALIGN="top"
><A
><A
HREF="language.database.html"
HREF="language.database.html"
ACCESSKEY="P"
ACCESSKEY="P"
>Prev</A
>Prev</A
></TD
></TD
><TD
><TD
WIDTH="34%"
WIDTH="34%"
ALIGN="center"
ALIGN="center"
VALIGN="top"
VALIGN="top"
><A
><A
HREF="cdl-guide.html"
HREF="cdl-guide.html"
ACCESSKEY="H"
ACCESSKEY="H"
>Home</A
>Home</A
></TD
></TD
><TD
><TD
WIDTH="33%"
WIDTH="33%"
ALIGN="right"
ALIGN="right"
VALIGN="top"
VALIGN="top"
><A
><A
HREF="build.headers.html"
HREF="build.headers.html"
ACCESSKEY="N"
ACCESSKEY="N"
>Next</A
>Next</A
></TD
></TD
></TR
></TR
><TR
><TR
><TD
><TD
WIDTH="33%"
WIDTH="33%"
ALIGN="left"
ALIGN="left"
VALIGN="top"
VALIGN="top"
>Updating the <SPAN
>Updating the <SPAN
CLASS="DATABASE"
CLASS="DATABASE"
>ecos.db</SPAN
>ecos.db</SPAN
> database</TD
> database</TD
><TD
><TD
WIDTH="34%"
WIDTH="34%"
ALIGN="center"
ALIGN="center"
VALIGN="top"
VALIGN="top"
>&nbsp;</TD
>&nbsp;</TD
><TD
><TD
WIDTH="33%"
WIDTH="33%"
ALIGN="right"
ALIGN="right"
VALIGN="top"
VALIGN="top"
>Configuration Header File Generation</TD
>Configuration Header File Generation</TD
></TR
></TR
></TABLE
></TABLE
></DIV
></DIV
></BODY
></BODY
></HTML
></HTML
 
 

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.