Difference between revisions of "XCDL packages"

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

Repositories

Packages and the local component repository

All development tools using XCDL packages include a local component repository. Similarly to the CMSIS Pack 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

Below each package directory there can be one or more version sub-directories, named after the versions. This is a requirement of the component framework: it must be possible for users to install multiple versions of a package and select which one to use for any given application. This has a number of advantages to users: most importantly it allows a single component repository to be shared between multiple users and multiple projects, as required; also it facilitates experiments, for example it is relatively easy to try out the latest version of some package and see if it makes any difference. There is a potential disadvantage in terms of disk space. However since XCDL packages generally consist of source code intended for small embedded systems, and given typical modern disk sizes, keeping a number of different versions of a package installed will usually be acceptable. The administration tool can be used to remove versions that are no longer required.

Packages/ARM
└── CMSIS
    ├── 3.20.3
    ├── 3.20.4
    ├── 4.1.0
    └── current

The version current is special. Typically it corresponds to the very latest version of the package.

All other subdirectories of a package correspond to specific releases of that package. The component frame- work allows users to select the particular version of a package they want to use, but by default the most recent one will be used. This requires some rules for ordering version numbers, a difficult task because of the wide variety of ways in which versions can be identified.

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.