--- /dev/null
+<!-- 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
+>The Build Process</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="PREVIOUS"
+TITLE="Updating the ecos.db database"
+HREF="language.database.html"><LINK
+REL="NEXT"
+TITLE="Configuration Header File Generation"
+HREF="build.headers.html"></HEAD
+><BODY
+CLASS="CHAPTER"
+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="language.database.html"
+ACCESSKEY="P"
+>Prev</A
+></TD
+><TD
+WIDTH="80%"
+ALIGN="center"
+VALIGN="bottom"
+></TD
+><TD
+WIDTH="10%"
+ALIGN="right"
+VALIGN="bottom"
+><A
+HREF="build.headers.html"
+ACCESSKEY="N"
+>Next</A
+></TD
+></TR
+></TABLE
+><HR
+ALIGN="LEFT"
+WIDTH="100%"></DIV
+><DIV
+CLASS="CHAPTER"
+><H1
+><A
+NAME="BUILD">Chapter 4. The Build Process</H1
+><DIV
+CLASS="TOC"
+><DL
+><DT
+><B
+>Table of Contents</B
+></DT
+><DT
+><A
+HREF="build.html#BUILD.OUTLINE"
+>Build Tree Generation</A
+></DT
+><DT
+><A
+HREF="build.headers.html"
+>Configuration Header File Generation</A
+></DT
+><DT
+><A
+HREF="build.make.html"
+>Building eCos</A
+></DT
+><DT
+><A
+HREF="build.tests.html"
+>Building Test Cases</A
+></DT
+></DL
+></DIV
+><P
+>Some <SPAN
+CLASS="APPLICATION"
+>CDL</SPAN
+> properties describe the consequences of manipulating
+configuration options. There are two main types of consequences.
+Typically enabling a configuration option results in one or more
+<TT
+CLASS="LITERAL"
+>#define's</TT
+> in a configuration header file, and
+properties that affect this include <SPAN
+CLASS="PROPERTY"
+>define</SPAN
+>, <SPAN
+CLASS="PROPERTY"
+>define_proc</SPAN
+> and
+<SPAN
+CLASS="PROPERTY"
+>no_define</SPAN
+>. Enabling a configuration option can also affect the build
+process, primarily determining which files get built and added to the
+appropriate library. Properties related to the build process include
+<SPAN
+CLASS="PROPERTY"
+>compile</SPAN
+> and <SPAN
+CLASS="PROPERTY"
+>make</SPAN
+>. This chapter describes the whole build process,
+including details such as compiler flags and custom build steps.</P
+><P
+>Part of the overall design of the <SPAN
+CLASS="APPLICATION"
+>eCos</SPAN
+> component framework is that
+it can interact with a number of different build systems. The most
+obvious of these is <SPAN
+CLASS="APPLICATION"
+>GNU
+make</SPAN
+>:the component framework can generate one or more
+makefiles, and the user can then build the various packages simply by
+invoking <SPAN
+CLASS="APPLICATION"
+>make</SPAN
+>. However it
+should also be possible to build <SPAN
+CLASS="APPLICATION"
+>eCos</SPAN
+> by other means: the
+component framework can be queried about what is involved in building
+a given configuration, and this information can then be fed into the
+desired build system. Component writers should be aware of this
+possibility. Most packages will not be affected because the <SPAN
+CLASS="PROPERTY"
+>compile</SPAN
+>
+property can be used to provide all the required information, but care
+has to be taken when writing custom build steps.</P
+><DIV
+CLASS="SECT1"
+><H1
+CLASS="SECT1"
+><A
+NAME="BUILD.OUTLINE">Build Tree Generation</H1
+><P
+>It is necessary to create an <SPAN
+CLASS="APPLICATION"
+>eCos</SPAN
+> configuration before anything can
+be built. With some tools such as the graphical configuration tool
+this configuration will be created in memory, and it is not essential
+to produce an <TT
+CLASS="FILENAME"
+>ecos.ecc</TT
+> savefile first (although
+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
+the savefile is generated first, for example using
+<TT
+CLASS="LITERAL"
+>ecosconfig new</TT
+>, and then a build tree is
+generated using <TT
+CLASS="LITERAL"
+>ecosconfig tree</TT
+>. The savefile
+contains all the information needed to recreate a configuration.</P
+><P
+>An <SPAN
+CLASS="APPLICATION"
+>eCos</SPAN
+> build actually involves three separate trees. The component
+repository acts as the source tree, and for application developers
+this should be considered a read-only resource. The build tree is
+where all intermediate files, especially object files, are created.
+The install tree is where the main library
+<TT
+CLASS="FILENAME"
+>libtarget.a</TT
+>, the exported header files, and
+similar files end up. Following a successful build it is possible to
+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
+needed for that. The build tree will be needed again only if the user
+changes the configuration. However the install tree does not contain
+copies of all of the documentation for the various packages, instead
+the documentation is kept only in the component repository.</P
+><P
+>By default the build tree, the install tree, and the
+<TT
+CLASS="FILENAME"
+>ecos.ecc</TT
+> savefile all reside in the same
+directory tree. This is not a requirement, both the install tree and
+the savefile can be anywhere in the file system.</P
+><P
+>It is worth noting that the component framework does not separate the
+usual <TT
+CLASS="LITERAL"
+>make</TT
+> and <TT
+CLASS="LITERAL"
+>make install</TT
+>
+stages. A build always populates the install tree, and any
+<TT
+CLASS="LITERAL"
+>make install</TT
+> step would be redundant.</P
+><P
+>The install tree will always begin with two directories, <TT
+CLASS="FILENAME"
+>include</TT
+> for the exported header files and
+<TT
+CLASS="FILENAME"
+>lib</TT
+> for the main library
+<TT
+CLASS="FILENAME"
+>libtarget.a</TT
+> and other files
+such as the linker script. In addition there will be a subdirectory
+<TT
+CLASS="FILENAME"
+>include/pkgconf</TT
+> containing the
+configuration header files, which are generated or updated at the same
+time the build tree is created or updated. More details of header file
+generation are given below. Additional <TT
+CLASS="FILENAME"
+>include</TT
+> subdirectories such as <TT
+CLASS="FILENAME"
+>sys</TT
+> and <TT
+CLASS="FILENAME"
+>cyg/kernel</TT
+> will be created during the
+first build, when each package's exported header files are copied to
+the install tree. The install tree may also end up with additional
+subdirectories during a build, for example as a result of custom build
+steps. </P
+><P
+>The component framework does not define the structure of the build
+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
+build tree, and that this directory will be used for storing the
+package's object files and as the current directory for any build
+steps for that package. This avoids problems when custom build steps
+from different packages generate intermediate files which happen to
+have the same name.</P
+><P
+>Some build systems may allow application developers to copy a source
+file from the component repository to the build tree and edit the
+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
+modify the master copy in the component repository which could be
+shared by several projects or several people. Functionality such as
+this is transparent to component writers, and it is the responsibility
+of the build system to make sure that the right thing happens.</P
+><DIV
+CLASS="NOTE"
+><BLOCKQUOTE
+CLASS="NOTE"
+><P
+><B
+>Note: </B
+>There are some unresolved issues related to the build tree and install
+tree. Specifically, when updating an existing build or install tree,
+what should happen to unexpected files or directories? Suppose the
+user started with a configuration that included the math library, and
+the install tree contains header files <TT
+CLASS="FILENAME"
+>include/math.h</TT
+> and <TT
+CLASS="FILENAME"
+>include/sys/ieeefp.h</TT
+>. The user then removed
+the math library from the configuration and is updating the build
+tree. It is now desirable to remove these header files from the
+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
+time. There will also be some object files in the existing
+<TT
+CLASS="LITERAL"
+>libtarget.a</TT
+> library which are no longer
+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
+directory for the math library, which no longer serves any purpose.</P
+><P
+>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
+removing them automatically would be a bad idea.</P
+><P
+>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
+determine which files or library members are obsolete and can safely
+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
+></BLOCKQUOTE
+></DIV
+></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.database.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="build.headers.html"
+ACCESSKEY="N"
+>Next</A
+></TD
+></TR
+><TR
+><TD
+WIDTH="33%"
+ALIGN="left"
+VALIGN="top"
+>Updating the <SPAN
+CLASS="DATABASE"
+>ecos.db</SPAN
+> database</TD
+><TD
+WIDTH="34%"
+ALIGN="center"
+VALIGN="top"
+> </TD
+><TD
+WIDTH="33%"
+ALIGN="right"
+VALIGN="top"
+>Configuration Header File Generation</TD
+></TR
+></TABLE
+></DIV
+></BODY
+></HTML
+>
\ No newline at end of file
projects / karo-tx-redboot.git / blobdiff