📄 build.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>The Build Process</TITLE><meta name="MSSmartTagsPreventParsing" content="TRUE"><METANAME="GENERATOR"CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+"><LINKREL="HOME"TITLE="The eCos Component Writer's Guide"HREF="cdl-guide.html"><LINKREL="PREVIOUS"TITLE="Updating the ecos.db database"HREF="language.database.html"><LINKREL="NEXT"TITLE="Configuration Header File Generation"HREF="build.headers.html"></HEAD><BODYCLASS="CHAPTER"BGCOLOR="#FFFFFF"TEXT="#000000"LINK="#0000FF"VLINK="#840084"ALINK="#0000FF"><DIVCLASS="NAVHEADER"><TABLESUMMARY="Header navigation table"WIDTH="100%"BORDER="0"CELLPADDING="0"CELLSPACING="0"><TR><THCOLSPAN="3"ALIGN="center">The <SPANCLASS="APPLICATION">eCos</SPAN> Component Writer's Guide</TH></TR><TR><TDWIDTH="10%"ALIGN="left"VALIGN="bottom"><AHREF="language.database.html"ACCESSKEY="P">Prev</A></TD><TDWIDTH="80%"ALIGN="center"VALIGN="bottom"></TD><TDWIDTH="10%"ALIGN="right"VALIGN="bottom"><AHREF="build.headers.html"ACCESSKEY="N">Next</A></TD></TR></TABLE><HRALIGN="LEFT"WIDTH="100%"></DIV><DIVCLASS="CHAPTER"><H1><ANAME="BUILD">Chapter 4. The Build Process</H1><DIVCLASS="TOC"><DL><DT><B>Table of Contents</B></DT><DT><AHREF="build.html#BUILD.OUTLINE">Build Tree Generation</A></DT><DT><AHREF="build.headers.html">Configuration Header File Generation</A></DT><DT><AHREF="build.make.html">Building eCos</A></DT><DT><AHREF="build.tests.html">Building Test Cases</A></DT></DL></DIV><P>Some <SPANCLASS="APPLICATION">CDL</SPAN> properties describe the consequences of manipulatingconfiguration options. There are two main types of consequences.Typically enabling a configuration option results in one or more<TTCLASS="LITERAL">#define's</TT> in a configuration header file, andproperties that affect this include <SPANCLASS="PROPERTY">define</SPAN>, <SPANCLASS="PROPERTY">define_proc</SPAN> and<SPANCLASS="PROPERTY">no_define</SPAN>. Enabling a configuration option can also affect the buildprocess, primarily determining which files get built and added to theappropriate library. Properties related to the build process include<SPANCLASS="PROPERTY">compile</SPAN> and <SPANCLASS="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 <SPANCLASS="APPLICATION">eCos</SPAN> component framework is thatit can interact with a number of different build systems. The mostobvious of these is <SPANCLASS="APPLICATION">GNUmake</SPAN>:the component framework can generate one or moremakefiles, and the user can then build the various packages simply byinvoking <SPANCLASS="APPLICATION">make</SPAN>. However itshould also be possible to build <SPANCLASS="APPLICATION">eCos</SPAN> by other means: thecomponent framework can be queried about what is involved in buildinga given configuration, and this information can then be fed into thedesired build system. Component writers should be aware of thispossibility. Most packages will not be affected because the <SPANCLASS="PROPERTY">compile</SPAN>property can be used to provide all the required information, but carehas to be taken when writing custom build steps.</P><DIVCLASS="SECT1"><H1CLASS="SECT1"><ANAME="BUILD.OUTLINE">Build Tree Generation</H1><P>It is necessary to create an <SPANCLASS="APPLICATION">eCos</SPAN> configuration before anything canbe built. With some tools such as the graphical configuration toolthis configuration will be created in memory, and it is not essentialto produce an <TTCLASS="FILENAME">ecos.ecc</TT> savefile first (althoughit is still very desirable to generate such a savefile at some point,to allow the configuration to be re-loaded later on). With other toolsthe savefile is generated first, for example using<TTCLASS="LITERAL">ecosconfig new</TT>, and then a build tree isgenerated using <TTCLASS="LITERAL">ecosconfig tree</TT>. The savefilecontains all the information needed to recreate a configuration.</P><P>An <SPANCLASS="APPLICATION">eCos</SPAN> build actually involves three separate trees. The componentrepository acts as the source tree, and for application developersthis should be considered a read-only resource. The build tree iswhere all intermediate files, especially object files, are created.The install tree is where the main library<TTCLASS="FILENAME">libtarget.a</TT>, the exported header files, andsimilar files end up. Following a successful build it is possible totake just the install tree and use it for developing an application:none of the files in the component repository or the build tree areneeded for that. The build tree will be needed again only if the userchanges the configuration. However the install tree does not containcopies of all of the documentation for the various packages, insteadthe documentation is kept only in the component repository.</P><P>By default the build tree, the install tree, and the<TTCLASS="FILENAME">ecos.ecc</TT> savefile all reside in the samedirectory tree. This is not a requirement, both the install tree andthe savefile can be anywhere in the file system.</P><P>It is worth noting that the component framework does not separate theusual <TTCLASS="LITERAL">make</TT> and <TTCLASS="LITERAL">make install</TT>stages. A build always populates the install tree, and any<TTCLASS="LITERAL">make install</TT> step would be redundant.</P><P>The install tree will always begin with two directories, <TTCLASS="FILENAME">include</TT> for the exported header files and<TTCLASS="FILENAME">lib</TT> for the main library<TTCLASS="FILENAME">libtarget.a</TT> and other filessuch as the linker script. In addition there will be a subdirectory<TTCLASS="FILENAME">include/pkgconf</TT> containing theconfiguration header files, which are generated or updated at the sametime the build tree is created or updated. More details of header filegeneration are given below. Additional <TTCLASS="FILENAME">include</TT> subdirectories such as <TTCLASS="FILENAME">sys</TT> and <TTCLASS="FILENAME">cyg/kernel</TT> will be created during thefirst build, when each package's exported header files are copied tothe install tree. The install tree may also end up with additionalsubdirectories during a build, for example as a result of custom buildsteps. </P><P>The component framework does not define the structure of the buildtree, and this may vary between build systems. It can be assumed thateach package in the configuration will have its own directory in thebuild tree, and that this directory will be used for storing thepackage's object files and as the current directory for any buildsteps for that package. This avoids problems when custom build stepsfrom different packages generate intermediate files which happen tohave the same name.</P><P>Some build systems may allow application developers to copy a sourcefile from the component repository to the build tree and edit thecopy. This allows users to experiment with small changes, for exampleto add a couple of lines of debugging to a package, without having tomodify the master copy in the component repository which could beshared by several projects or several people. Functionality such asthis is transparent to component writers, and it is the responsibilityof the build system to make sure that the right thing happens.</P><DIVCLASS="NOTE"><BLOCKQUOTECLASS="NOTE"><P><B>Note: </B>There are some unresolved issues related to the build tree and installtree. Specifically, when updating an existing build or install tree,what should happen to unexpected files or directories? Suppose theuser started with a configuration that included the math library, andthe install tree contains header files <TTCLASS="FILENAME">include/math.h</TT> and <TTCLASS="FILENAME">include/sys/ieeefp.h</TT>. The user then removedthe math library from the configuration and is updating the buildtree. It is now desirable to remove these header files from theinstall tree, so that if any application code still attempts to usethe math library this will fail at compile time rather than at linktime. There will also be some object files in the existing<TTCLASS="LITERAL">libtarget.a</TT> library which are no longerappropriate, and there may be other files in the install tree as aresult of custom build steps. The build tree will still contain adirectory 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 treeor the install tree were placed there by the user, in which caseremoving them automatically would be a bad idea.</P><P>At present the component framework does not keep track of exactly whatshould be present in the build and install trees, so it cannot readilydetermine which files or library members are obsolete and can safelybe removed, and which ones are unexpected and need to be reported tothe user. This will be addressed in a future release of the system.</P></BLOCKQUOTE></DIV></DIV></DIV><DIVCLASS="NAVFOOTER"><HRALIGN="LEFT"WIDTH="100%"><TABLESUMMARY="Footer navigation table"WIDTH="100%"BORDER="0"CELLPADDING="0"CELLSPACING="0"><TR><TDWIDTH="33%"ALIGN="left"VALIGN="top"><AHREF="language.database.html"ACCESSKEY="P">Prev</A></TD><TDWIDTH="34%"ALIGN="center"VALIGN="top"><AHREF="cdl-guide.html"ACCESSKEY="H">Home</A></TD><TDWIDTH="33%"ALIGN="right"VALIGN="top"><AHREF="build.headers.html"ACCESSKEY="N">Next</A></TD></TR><TR><TDWIDTH="33%"ALIGN="left"VALIGN="top">Updating the <SPANCLASS="DATABASE">ecos.db</SPAN> database</TD><TDWIDTH="34%"ALIGN="center"VALIGN="top"> </TD><TDWIDTH="33%"ALIGN="right"VALIGN="top">Configuration Header File Generation</TD></TR></TABLE></DIV></BODY></HTML>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -