Difference between revisions of "XCDL packages"

Revision as of 17:05, 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.

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

The usual method of distributing XCDL packages is via http resources, commonly single archive files.

Individual packages

For individually distributed archived packages, the component framework should be able to manage these files, unpack and add their content to the local component repository.

Git/local development trees

For component developers the usual package life cycle of pack/publish/fetch/unpack is not only useless, but may have a significant impact on the speed of the debug/test cycle.

For these cases it should be possible to directly use local folders where the packages are already unpacked.

Since these development folders are usually linked to revision control systems (like Git), another useful feature for the component framework would be to directly manage remote Git repositories.

TODO: define details

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.