From 4f8346442c3b7ab3abe54362d844171f7f865ba1 Mon Sep 17 00:00:00 2001 From: Richard Purdie Date: Tue, 28 Apr 2009 08:24:47 +0100 Subject: handbook: Add more information about extending Poky Add more details on using in a team environment and how collections can be used to manage groups of different kinds of changes Signed-off-by: Richard Purdie --- handbook/extendpoky.xml | 95 +++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 92 insertions(+), 3 deletions(-) (limited to 'handbook') diff --git a/handbook/extendpoky.xml b/handbook/extendpoky.xml index f259d2ef0a..fa789d4afb 100644 --- a/handbook/extendpoky.xml +++ b/handbook/extendpoky.xml @@ -26,7 +26,15 @@ - The simplest way to add a new package is to base it on a similar + Before writing a recipe from scratch it is often useful to check + someone else hasn't written one already. OpenEmbedded is a good place + to look as it has a wider scope and hence a wider range of packages. + Poky aims to be compatible with OpenEmbedded so most recipes should + just work in Poky. + + + + For new packages, the simplest way to add a recipe is to base it on a similar pre-existing recipe. There are some examples below of how to add standard types of packages: @@ -556,6 +564,37 @@ BBFILE_PRIORITY_extras = "5" +
+ Supplementry Metadata Repositories + + + Often when developing a project based on Poky there will be components + that are not ready for public consumption for whatever reason. By making + use of the collections mechanism and other functionality within Poky, it + is possible to have a public repository which is supplemented by a private + one just containing the pieces that need to be kept private. + + + The usual approach with these is to create a separate git repository called + "meta-prvt-XXX" which is checked out alongside the other meta-* + directories included in Poky. Under this directory there can be several + different directories such as classes, conf and packages which all + function as per the usual Poky directory structure. + + + If extra meta-* directories are found, Poky will automatically add them + into the BBPATH variable so the conf and class files contained there + are found. If a file called poky-extra-environment is found within the + meta-* directory, this will be sourced as the environment is setup, + allowing certain configuration to be overridden such as the location of the + local.conf.sample file that is used. + + + Note that at present, BBFILES is not automatically changed and this needs + to be adjusted to find files in the packages/ directory. Usually a custom + local.conf.sample file will be used to handle this instead. + +
Committing Changes @@ -564,8 +603,8 @@ BBFILE_PRIORITY_extras = "5" Modifications to Poky are often managed under some kind of source revision control system. The policy for committing to such systems is important as some simple policy can significantly improve - usability. The tips below are based on the policy that OpenedHand - uses for commits to Poky. + usability. The tips below are based on the policy followed for the + Poky core. @@ -622,6 +661,56 @@ BBFILE_PRIORITY_extras = "5" upgradable packages in all cases.
+
+ Using Poky in a Team Environment + + + It may not be immediately clear how Poky can work in a team environment, + or scale to a large team of developers. The specifics of any situation + will determine the best solution and poky offers immense flexibility in + that aspect but there are some practises that experience has shown to work + well. + + + + The core component of any development effort with Poky is often an + automated build testing framework and image generation process. This + can be used to check that the metadata is buildable, highlight when + commits break the builds and provide up to date images allowing people + to test the end result and use them as a base platform for further + development. Experience shows that buildbot is a good fit for this role + and that it works well to configure it to make two types of build - + incremental builds and 'from scratch'/full builds. The incremental builds + can be tied to a commit hook which triggers them each time a commit is + made to the metadata and are a useful acid test of whether a given commit + breaks the build in some serious way. They catch lots of simple errors + and whilst they won't catch 100% of failures, the tests are fast so + developers can get feedback on their changes quickly. The full builds + are builds that build everything from the ground up and test everything. + They usually happen at preset times such as at night when the machine + load isn't high from the incremental builds. + + + + Most teams have pieces of software undergoing active development. It is of + significant benefit to put these under control of a source control system + compatible with Poky such as git or svn. The autobuilder can then be set to + pull the latest revisions of these packages so the latest commits get tested + by the builds allowing any issues to be highlighted quickly. Poky easily + supports configurations where there is both a stable known good revision + and a floating revision to test. Poky can also only take changes from specific + source control branches giving another way it can be used to track/test only + specified changes. + + + Perhaps the hardest part of setting this up is the policy that surrounds + the different source control systems, be them software projects or the Poky + metadata itself. The circumstances will be different in each case but this is + one of Poky's advantages - the system itself doesn't force any particular policy + unlike a lot of build systems, allowing the best policy to be chosen for the + circumstances. + +
-- cgit 1.2.3-korg