Difference between revisions of "XCDL packages"
m (→Packages and the local component repository) |
m |
||
| Line 47: | Line 47: | ||
└── CyaSSL | └── CyaSSL | ||
</pre> | </pre> | ||
| + | |||
| + | == Remote/archived repositories == | ||
| + | |||
| + | TBD | ||
| + | |||
| + | == Repository content brief == | ||
| + | |||
| + | For each remote repository there is a summary content.xml file enumerating the public packages available on the remote location. | ||
| + | |||
| + | The content.xml files hold the list of installed packages and is managed by the administration tool. The various configuration tools read in these files when they start-up to obtain information about the various packages that have been installed. | ||
== Package Versioning == | == Package Versioning == | ||
Revision as of 17:47, 21 June 2014
For a package to be usable in the XCDL component framework it must conform to certain rules imposed by that framework. Packages must be distributed in a form that is understood by the component repository administration tool. There must be a top-level XCDL file which describes the package to the component framework. There are certain limitations related to how a package gets built, so that the package can still be used in a variety of host environments. In addition to these rules, the component framework provides a number of guidelines. Packages do not have to conform to the guidelines, but sticking to them can simplify certain operations.
Contents
Packages and the local component repository
All development tools using XCDL packages include a local component repository. This is a local folder structure where installed packages are located. The component framework comes with an administration tool that allows new packages or new versions of a package to be installed, old packages to be removed, and so on. Each package has its own little directory hierarchy within the component repository. Keeping several packages in a single directory is illegal. There are no strict rules defining where new packages should get installed.
To better accommodate the package separation for multi-vendor cases, the local folder hierarchy start with a folder with the vendor name.
Packages/ ├── ARM ├── Keil ├── Nuvoton ├── lwIP └── wolfSSL
Below each vendor there are hierarchies of packages. Unrelated packages are all stored just below the vendor folder.
Packages
├── ARM
│ └── CMSIS
├── Keil
│ ├── ARMCortex_DFP
│ ├── Kinetis_K10_DFP
│ ├── Kinetis_KLxx_DFP
│ ├── MCB1500_BSP
│ ├── MDK-Middleware
│ ├── SAMD21_DFP
│ ├── STM32F0xx_DFP
│ ├── STM32F1xx_DFP
│ ├── STM32F2xx_DFP
│ ├── STM32F3xx_DFP
│ ├── STM32F4xx_DFP
│ ├── STM32L0xx_DFP
│ ├── STM32L1xx_DFP
│ ├── STM32NUCLEO_BSP
│ ├── STM32W1xx_DFP
│ ├── TMPM3_DFP
│ └── V2M-MPS2_CMx_BSP
├── Nuvoton
│ └── NuMicro_DFP
├── lwIP
│ └── lwIP
└── wolfSSL
└── CyaSSL
Remote/archived repositories
TBD
Repository content brief
For each remote repository there is a summary content.xml file enumerating the public packages available on the remote location.
The content.xml files hold the list of installed packages and is managed by the administration tool. The various configuration tools read in these files when they start-up to obtain information about the various packages that have been installed.
Package Versioning
TBD
Package contents and layout
TBD
Outline of the build process
TBD
Configurable source code
TBD
Exported header files
TBD
Package Documentation
TBD
Test Cases
TBD
Host-side support
TBD
Making a Package Distribution
TBD
The XCDL package distribution file format
TBD
Preparing XCDL packages for distribution
TBD
Credits
The content of this page is based on Chapter 2. Package Organizaion of The eCos Component Writer’s Guide, by Bart Veer and John Dallaway, published in 2001.
