Difference between revisions of "Scratchpad"

Revision as of 11:20, 20 March 2015

These are notes on various decisions that need to be made, with the available choices, with pros and cons.

make vs. python

Two candidates for the build systems are considered:

• make
• something based on python, like SCons

make pros

• well-known
• available on all platforms (separate install on Windows, but available)

make cons

• considered not very efficient by some

python pros

• extending the build process is very powerful

python cons

• may face acceptance problems, like SCons

Thoughts

Only as internal builder, probably it does not matter. It was easier to start pyXCDL with make files, and performance was not a problem.

However, for writing recipes, like for BitBake, an object oriented approach in Python might have advantages.

python2 vs python3

This is no longer an issue, there are no reasons for not using it.

• the project is new, there is no legacy code (pyXCDL need not be used as is, it can be ported)
• python3 is available on all platforms

Self contained packages vs. recipes

It looks like there are two ways of handling dependencies on external packages:

• when xcdl packages are created
• when the user downloads the packages

The initial approach considered that packages contain original code, and their content should be self contained.

Experience proved that many packages contain code from other sources, like vendor libraries, and sometimes these libraries need patches.

Maintaining these patches requires a separate branch in the repository, and periodic merges into the master branch.

For libraries distributed as archives, an automated procedure to update this separate branch would be useful.

The BitBake alternative is to delay the original archive fetch to the moment when the XCDL package is installed on the user machine, and to run a procedure there to prepare the actual package content.

This might save some space in the package repository, which need not include huge vendor libraries, but keep only recipes, but has the disadvantages that forwards the responsibility of a correct fetch to the user (the archive server must be available, the user computer needs to have enough space to store all initial archives, as the patched ones).

The current favourite is the first choice, to process the archive when the package is created.

Package content & build scenarios

There are several possibilities to create a package:

1. original local code: the entire code resides in the project;
2. original external code: some code is downloaded from an archive, a repository, in BitBake style; no patches;
3. patched external code: the original code resides in a separate branch, merged to the master.

In all cases, only a selection of the files are packed in the final package, based on a MANIFEST file.

For 2 & 3, it is possible to pack only the recipe and ask the package manager to prepare the actual package.