1 <!-- Copyright (C) 2003 Red Hat, Inc. -->
2 <!-- This material may be distributed only subject to the terms -->
3 <!-- and conditions set forth in the Open Publication License, v1.0 -->
4 <!-- or later (the latest version is presently available at -->
5 <!-- http://www.opencontent.org/openpub/). -->
6 <!-- Distribution of the work or derivative of the work in any -->
7 <!-- standard (paper) book form is prohibited unless prior -->
8 <!-- permission is obtained from the copyright holder. -->
12 >Updating the ecos.db database</TITLE
13 ><meta name="MSSmartTagsPreventParsing" content="TRUE">
16 CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
19 TITLE="The eCos Component Writer's Guide"
20 HREF="cdl-guide.html"><LINK
22 TITLE="The CDL Language"
23 HREF="language.html"><LINK
26 HREF="language.interface.html"><LINK
28 TITLE="The Build Process"
29 HREF="build.html"></HEAD
40 SUMMARY="Header navigation table"
52 > Component Writer's Guide</TH
60 HREF="language.interface.html"
68 >Chapter 3. The CDL Language</TD
88 NAME="LANGUAGE.DATABASE">Updating the <SPAN
93 >The current implementation of the component framework requires that
94 all packages be present in a single component repository and listed in
95 that repository's <SPAN
98 > database. This is not
99 generally a problem for application developers who can consider the
100 component repository a read-only resource, except when adding or
101 removing packages via the administration tool. However it means that
102 component writers need to do their development work inside a
103 component repository as well, and update the database with details of
104 their new package or packages. Future enhancements to the component
105 framework may allow new components to be developed outside a
108 >Like most files related to the component framework, the
112 > database is actually a <SPAN
116 Typical package entries would look like this:</P
124 CLASS="PROGRAMLISTING"
125 >package CYGPKG_LIBC {
126 alias { "C library" libc clib clibrary }
127 directory language/c/libc
130 This package enables compatibility with the ISO C standard - ISO/IEC
131 9899:1990. This allows the user application to use well known standard
132 C library functions, and in eCos starts a thread to invoke the user
136 package CYGPKG_IO_PCI {
137 alias { "PCI configuration library" io_pci }
142 This package contains the PCI configuration library."
151 > command takes two arguments, a name and
152 a body. The name must be the same as in the <TT
156 the package's top-level <SPAN
159 > script. The body can contain the
160 following five commands: <TT
190 >Each package should have one or more aliases. The first alias is
191 typically used when listing the known packages, because a string like
195 > is a bit easier to read and
199 >. The other aliases are
200 not used for output, but are accepted on input. For example the
208 > as an option, as well
211 >add CYGPKG_LIBC</TT
221 >This is used to specify the location of the package relative to the
222 root of the component repository. It should be noted that in the
223 current component framework this location cannot be changed in
224 subsequent releases of the package: if for some reason it is desirable
225 to install a new release elsewhere in the repository, all the old
226 versions must first be uninstalled; the database cannot hold two
227 separate locations for one package.</P
239 > command specifies the location of the
240 package's top-level <SPAN
243 > script, in other words the one containing the
247 > definition. If the package follows the <A
248 HREF="package.html#PACKAGE.HIERARCHY"
249 >directory layout conventions</A
251 this script will be in the <TT
255 sub-directory, otherwise it will be relative to the package's top-level
256 directory. Again once a release has been made this file should not
257 change in later releases. In practice the top-level script is generally
258 named after the package itself, so changing its name is unlikely to be
268 >Packages which are tied to specific hardware, for example device
269 drivers and HAL packages, should indicate this in both the
273 > command of the <SPAN
276 > script and in the database entry.</P
285 >This should give a brief description of the package. Typically the
289 > property in the <TT
304 >Most of the information in the <SPAN
308 be obtained by a relatively simple utility. This would be passed a
309 single argument identifying a package's top-level <SPAN
313 directory path relative to the component repository root could be
314 determined from the filename. The name, <TT
321 > fields could be obtained from the
328 > property would supply
329 the first alias, additional aliases could be obtained by extending the
330 syntax of that property or by other means. Something along these lines
331 may be provided by a future release of the component framework.</P
338 > database also holds
339 information about the various targets. When porting to a new target it
340 will be necessary to add information about the target to the database,
341 as well as the details of the new platform HAL package and any related
349 SUMMARY="Footer navigation table"
360 HREF="language.interface.html"
369 HREF="cdl-guide.html"
402 >The Build Process</TD
projects / karo-tx-redboot.git / blob