Conary:Build Source Tour
From rPath Wiki
| Conary Developer Community | Go to the community main page |
Guided Tour of Conary's build code
This tour is meant to give you some perspective on the conary/build/*.py files. It's not complete, but should give you the context you need to follow through the code and know where to look for details.
This is particularly important right now, since documentation is lacking and the code changes so much that documentation has trouble keeping up. There is quite a bit of structured documentation in-line, and knowing something about the build subdirectory will help you know where to look to find that documentation.
The contents of this directory are driven from recipe.py, but do not start by trying to understand *recipe.py, because it is hard to understand them if you do not know anything about the archicture. Instead, here are the important points to know about them initially:
- They define the
Recipeclass from which all recipes are derived, and all the internal conary recipe classes. - The
_AbstractPackageRecipeclass in packagerecipe.py intelligently multiplexes calls into multiple namespaces
Building a package then happens in phases, as documented in Conary Recipe. All the source actions are implemented in source.py (in a recipe, they are prefixed with add), the build actions in build.py, policy is driven by cook.py, using a superclass defined in policy.py and implemented in destdirpolicy.py, packagepolicy,py, and everything in the conary-policy package.
- All actions are added in order to the list of actions to take; each invocation automatically adds another instantiated object to the list. All actions are run before any build commands are run, even if they follow build commands in the recipe; this enables the option of logical rather than procedural grouping.
- All build commands are added in order to the list of build commands to run. Like actions, each invocation automatically adds another instantiated object to the list; the difference is that it is added to the build list instead of the action list.
Other files:
- policy.py has the guts of policy that allow individual policy modules to be small
- filter.py is the "extended regexp with file mode comparison operations" implementation
- macros.py is a self-interpolating dictionary
- use.py implements the
UseandArchobjects that recipes can use to control building. - usergroup.py Provides information for user and group creation through user info recipes or group info recipes.
