Scratchpad

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.