| Summary: | Add a small section on dependencies in the Writing a New Recipe section | ||
|---|---|---|---|
| Product: | [Documentation] Development Manual | Reporter: | Paul Eggleton <bluelightning> |
| Component: | development | Assignee: | Scott Rifenbark <srifenbark> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | Medium+ | CC: | jhaws, srifenbark |
| Version: | 2.1 | ||
| Target Milestone: | 2.2 M4 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | 04 Oct 2016: RESOLVED | ||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Done (doc changes complete) | |
|
Description
Paul Eggleton
2016-05-26 21:12:18 UTC
Specifically, for my problem, how the suffix _${PN} applies to each one (or doesn't apply) would be helpful.
Paul, Can you get me some explanation on this? I will work from that for the new section. Scott Adding myself to the CC list. OK, here's the raw material. This new subsection should go after the "Licensing" one.
---------- snip ----------
Dependencies
Most software packages have a short list of other packages that they require. These fall into two main categories - build-time dependencies (required when the software is built) and runtime dependencies (required to be installed on the target for the software to run).
Within a recipe, you specify build-time dependencies using the DEPENDS variable. There are some nuances, but for the most part items specified in DEPENDS should be names of other recipes. It is important to specify all build-time dependencies explicitly, otherwise due to the parallel nature of bitbake's execution you can end up with a race condition where the depency is present for one task of a recipe (e.g. do_configure) and then gone when the next task runs (e.g. do_compile). Another consideration is that configure scripts may automatically check for optional dependencies and enable corresponding functionality if they are found - this means that to ensure you get deterministic results (and avoid more race conditions) you need to either explicitly specify these dependencies as well, or tell the configure script explicitly to disable the functionality. If you wish to make a recipe that's more generally useful (particularly if you're going to publish the recipe in a layer for others to use), instead of hard-disabling the functionality you can use the PACKAGECONFIG variable to allow functionality and the corresponding dependencies to be enabled and disabled easily by other users of the recipe.
Likewise, runtime dependencies are specified through RDEPENDS - however, RDEPENDS is package-specific. All variables that are package-specific need to have the name of the package added to the end as an override. Since the main package for a recipe has the same name as the recipe, and the recipe's name can be found through the ${PN} variable, then you specify the dependencies for the main package by setting RDEPENDS_${PN}; if the package were named ${PN}-tools, then you would set RDEPENDS_${PN}-tools, and so on.
Some runtime dependencies will be set automatically at packaging time - these include any shared library dependencies i.e., if a package "example" contains "libexample" and another package "mypackage" contains a binary that links to "libexample" then the OpenEmbedded build system will automatically add a runtime dependency to "mypackage" on "example". See "Automatically Added Runtime Dependencies" in the reference manual for further details.
---------- snip ----------
Paul, See http://www.yoctoproject.org/docs/2.2/dev-manual/dev-manual.html#new-dependencies for the new section. Thanks, Scott Per separate email from Paul Eggleton, the changes here have been reviewed and approved. I am setting the bug to RESOLVED and putting the doc flag to "done." Scott Actually I'd forgot to review that as well, but I just did now and it looks good. |