--- /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
+>Package Structure</TITLE
+><meta name="MSSmartTagsPreventParsing" content="TRUE">
+<META
+NAME="GENERATOR"
+CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
+"><LINK
+REL="HOME"
+TITLE="eCos User Guide"
+HREF="ecos-user-guide.html"><LINK
+REL="UP"
+TITLE="Managing the Package Repository"
+HREF="managing-package-repository.html"><LINK
+REL="PREVIOUS"
+TITLE="Managing the Package Repository"
+HREF="managing-package-repository.html"><LINK
+REL="NEXT"
+TITLE="Appendixes"
+HREF="appendices.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"
+>eCos User Guide</TH
+></TR
+><TR
+><TD
+WIDTH="10%"
+ALIGN="left"
+VALIGN="bottom"
+><A
+HREF="managing-package-repository.html"
+ACCESSKEY="P"
+>Prev</A
+></TD
+><TD
+WIDTH="80%"
+ALIGN="center"
+VALIGN="bottom"
+>Chapter 29. Managing the Package Repository</TD
+><TD
+WIDTH="10%"
+ALIGN="right"
+VALIGN="bottom"
+><A
+HREF="appendices.html"
+ACCESSKEY="N"
+>Next</A
+></TD
+></TR
+></TABLE
+><HR
+ALIGN="LEFT"
+WIDTH="100%"></DIV
+><DIV
+CLASS="SECT1"
+><H1
+CLASS="SECT1"
+><A
+NAME="PACKAGE-STRUCTURE">Package Structure</H1
+><P
+>The files in an installed <SPAN
+CLASS="PRODUCTNAME"
+>eCos</SPAN
+> source tree are organized in
+a natural tree structure, grouping together files which work together
+into <SPAN
+CLASS="emphasis"
+><I
+CLASS="EMPHASIS"
+>Packages</I
+></SPAN
+>. For example, the kernel files
+are all together in: </P
+><P
+></P
+><TABLE
+BORDER="0"
+><TBODY
+><TR
+><TD
+><TT
+CLASS="FILENAME"
+><TT
+CLASS="REPLACEABLE"
+><I
+>BASE_DIR</I
+></TT
+>/kernel/<TT
+CLASS="REPLACEABLE"
+><I
+><version></I
+></TT
+>/include/</TT
+></TD
+></TR
+><TR
+><TD
+> <TT
+CLASS="FILENAME"
+><TT
+CLASS="REPLACEABLE"
+><I
+>BASE_DIR</I
+></TT
+>/kernel/<TT
+CLASS="REPLACEABLE"
+><I
+><version></I
+></TT
+>/src/</TT
+></TD
+></TR
+><TR
+><TD
+> <TT
+CLASS="FILENAME"
+><TT
+CLASS="REPLACEABLE"
+><I
+>BASE_DIR</I
+></TT
+>/kernel/<TT
+CLASS="REPLACEABLE"
+><I
+><version></I
+></TT
+>/tests/</TT
+></TD
+></TR
+></TBODY
+></TABLE
+><P
+></P
+><P
+>and µITRON compatibility layer files are in:
+ </P
+><P
+></P
+><TABLE
+BORDER="0"
+><TBODY
+><TR
+><TD
+> <TT
+CLASS="FILENAME"
+><TT
+CLASS="REPLACEABLE"
+><I
+>BASE_DIR</I
+></TT
+>/compat/uitron/<TT
+CLASS="REPLACEABLE"
+><I
+><version></I
+></TT
+>/include/</TT
+></TD
+></TR
+><TR
+><TD
+> <TT
+CLASS="FILENAME"
+><TT
+CLASS="REPLACEABLE"
+><I
+>BASE_DIR</I
+></TT
+>/compat/uitron/<TT
+CLASS="REPLACEABLE"
+><I
+><version></I
+></TT
+>/src/</TT
+></TD
+></TR
+><TR
+><TD
+> <TT
+CLASS="FILENAME"
+><TT
+CLASS="REPLACEABLE"
+><I
+>BASE_DIR</I
+></TT
+>/compat/uitron/<TT
+CLASS="REPLACEABLE"
+><I
+><version></I
+></TT
+>/tests/</TT
+></TD
+></TR
+></TBODY
+></TABLE
+><P
+></P
+><P
+>The feature of these names which is of interest here is
+ the <TT
+CLASS="REPLACEABLE"
+><I
+><version></I
+></TT
+> near the end. It may seem odd to place a version number deep in the
+ path, rather than having something like
+ <TT
+CLASS="FILENAME"
+><TT
+CLASS="REPLACEABLE"
+><I
+>BASE_DIR</I
+></TT
+>/<TT
+CLASS="REPLACEABLE"
+><I
+><version></I
+></TT
+>/...everything...</TT
+>
+ or leaving it up to you to choose a different
+ install-place when a new release of the system arrives.
+ </P
+><P
+>There is a rationale for this organization: as
+ indicated, the kernel and the
+ µITRON compatibility subsystem
+ are examples of software packages. For the first few
+ releases of <SPAN
+CLASS="PRODUCTNAME"
+>eCos</SPAN
+>, all the packages will move along
+ in step, i.e. Release 1.3.x will feature Version
+ 1.3.x of every package, and so forth. But in future,
+ especially when third party packages become available, it is
+ intended that the package be the unit of software
+ distribution, so it will be possible to build a system from
+ a selection of packages with different version numbers, and
+ even differing versioning <SPAN
+CLASS="emphasis"
+><I
+CLASS="EMPHASIS"
+>schemes</I
+></SPAN
+>. A
+ Tcl script <B
+CLASS="COMMAND"
+>ecosadmin.tcl</B
+> is
+ provided in the <SPAN
+CLASS="PRODUCTNAME"
+>eCos</SPAN
+> repository to manage the installation
+ and removal of packages in this way.</P
+><P
+>Many users will have their own source code control system,
+version control system or equivalent, and will want to use it with
+<SPAN
+CLASS="PRODUCTNAME"
+>eCos</SPAN
+> sources. In that case, since a new release of <SPAN
+CLASS="PRODUCTNAME"
+>eCos</SPAN
+> comes with
+different pathnames for all the source files, a bit of work is necessary
+to import a new release into your source repository. </P
+><P
+>One way of handling the import is to rename all the version
+parts to some common name, for example “current”,
+and continue to work. “current” is suggested because <B
+CLASS="COMMAND"
+>ecosconfig</B
+> recognizes
+it and places it first in any list of versions. In the future, we
+may provide a tool to help with this, or an option in the install
+wizard. Alternatively, in a POSIX shell environment (Linux or Cygwin
+on Windows) use the following command: </P
+><TABLE
+BORDER="5"
+BGCOLOR="#E0E0F0"
+WIDTH="70%"
+><TR
+><TD
+><PRE
+CLASS="SCREEN"
+>find . -name <TT
+CLASS="REPLACEABLE"
+><I
+><version></I
+></TT
+> -type d -printf 'mv %p %h/current\n' | sh</PRE
+></TD
+></TR
+></TABLE
+><P
+>Having carried out such a renaming operation, your
+ source tree will now look like this: </P
+><TABLE
+BORDER="5"
+BGCOLOR="#E0E0F0"
+WIDTH="70%"
+><TR
+><TD
+><PRE
+CLASS="SCREEN"
+><TT
+CLASS="REPLACEABLE"
+><I
+>BASE_DIR</I
+></TT
+>/kernel/current/include/
+<TT
+CLASS="REPLACEABLE"
+><I
+>BASE_DIR</I
+></TT
+>/kernel/current/src/
+<TT
+CLASS="REPLACEABLE"
+><I
+>BASE_DIR</I
+></TT
+>/kernel/current/tests/
+ ...
+<TT
+CLASS="REPLACEABLE"
+><I
+>BASE_DIR</I
+></TT
+>/compat/uitron/current/include/
+<TT
+CLASS="REPLACEABLE"
+><I
+>BASE_DIR</I
+></TT
+>/compat/uitron/current/src/
+<TT
+CLASS="REPLACEABLE"
+><I
+>BASE_DIR</I
+></TT
+>/compat/uitron/current/tests/
+ </PRE
+></TD
+></TR
+></TABLE
+><P
+>which is a suitable format for import into your own
+ source code control system. When you get a subsequent
+ release of <SPAN
+CLASS="PRODUCTNAME"
+>eCos</SPAN
+>, do the same thing and use your own source
+ code control system to manage the new source base, by
+ importing the new version from </P
+><TABLE
+BORDER="5"
+BGCOLOR="#E0E0F0"
+WIDTH="70%"
+><TR
+><TD
+><PRE
+CLASS="SCREEN"
+><TT
+CLASS="REPLACEABLE"
+><I
+>NEW_BASE_DIR</I
+></TT
+>/kernel/current/include/</PRE
+></TD
+></TR
+></TABLE
+><P
+>and so on. </P
+><P
+>The <SPAN
+CLASS="PRODUCTNAME"
+>eCos</SPAN
+> build tool will now offer only the
+ “current” version of each package; select this
+ for the packages you wish to use. </P
+><P
+>Making such a change has implications for any build
+ trees you already have in use. A configured build tree
+ contains information about the selected packages and their
+ selected versions. Changing the name of the
+ “versioning” folder in the source tree
+ invalidates this information, and in consequence it also
+ invalidates any local configuration options you have set up
+ in this build tree. So if you want to change the version
+ information in the source tree, do it first, before
+ investing any serious time in configuring and building your
+ system. When you create a new build tree to deal with the
+ new source layout, it will contain default settings for all
+ the configuration options, just like the old build tree did
+ before you configured it. You will need to redo that
+ configuration work in the new tree. </P
+><P
+>Moving source code around also invalidates debugging information
+in any programs or libraries built from the old tree; these will
+need to be rebuilt. </P
+></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="managing-package-repository.html"
+ACCESSKEY="P"
+>Prev</A
+></TD
+><TD
+WIDTH="34%"
+ALIGN="center"
+VALIGN="top"
+><A
+HREF="ecos-user-guide.html"
+ACCESSKEY="H"
+>Home</A
+></TD
+><TD
+WIDTH="33%"
+ALIGN="right"
+VALIGN="top"
+><A
+HREF="appendices.html"
+ACCESSKEY="N"
+>Next</A
+></TD
+></TR
+><TR
+><TD
+WIDTH="33%"
+ALIGN="left"
+VALIGN="top"
+>Managing the Package Repository</TD
+><TD
+WIDTH="34%"
+ALIGN="center"
+VALIGN="top"
+><A
+HREF="managing-package-repository.html"
+ACCESSKEY="U"
+>Up</A
+></TD
+><TD
+WIDTH="33%"
+ALIGN="right"
+VALIGN="top"
+>Appendixes</TD
+></TR
+></TABLE
+></DIV
+></BODY
+></HTML
+>
\ No newline at end of file
projects / karo-tx-redboot.git / blobdiff