Difference between revisions of "Scratchpad"
m |
m |
||
| Line 1: | Line 1: | ||
| − | == make vs python == | + | == make vs. python == |
Two candidates for the build systems are considered: | Two candidates for the build systems are considered: | ||
| Line 30: | Line 30: | ||
* the project is new, there is no legacy code (pyXCDL need not be used as is, it can be ported) | * 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 | * 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 | ||
| + | * at user first build | ||
| + | |||
| + | 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. | ||
Revision as of 09:30, 20 March 2015
Contents
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
- at user first build
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.
