Styleguide: Difference between revisions

From Openembedded.org
Jump to navigation Jump to search
(oops, PROVIDES belongs near the top)
No edit summary
 
(13 intermediate revisions by 3 users not shown)
Line 1: Line 1:
= Naming Conventions =
This page has moved to the [https://docs.yoctoproject.org/dev/contributor-guide/recipe-style-guide.html Yocto Documentation Contributors Guide]
 
[[Versioning Policy|Use $packagename_$version.bb]]
 
= Format Guidelines =
 
* The correct spacing for a variable assignment is FOO = "BAR".
* Use quotes on the right hand side of assignments: FOO = "BAR"
* No spaces are allowed behind the line continuation symbol (\)
* Comments are allowed using the '#' character at the beginning of a line, but you cannot use a comment within a continuation.
* Use spaces for indentation as developers tends to use different amount of spaces per one tab.
* Indentation of multiline variables such as SRC_URI is desireable.
* Python functions must be four space indented - no tabs.
* Shell functions in OE-Core usually use tabs for indentation, but other layers usually use consistent indentation with 4 spaces (in shell functions, python functions and for indentation of multi-line variables)
* Closing quote for multiline variables is preferably first character on its own line, when the first line is long, then it's better to start with "\ and put first value on 2nd line
  FOO = "\
      bar \
      done \
  "
 
= Style Checking tools =
 
Please run ./contrib/oe-stylize.py on your recipes before submitting them.
 
= Style Guidelines =
 
== Additional Metadata ==
 
All recipes should aim to specify the following fields where possible:
 
* '''SUMMARY''': should give an 80 character/one line maximum short summary of the description.
* '''DESCRIPTION''': should give an extended (possibly multi-line) description of what recipe provides. Note that by default, DESCRIPTION is set to the value of SUMMARY, so if you only have a short description to use, just set SUMMARY.
* '''HOMEPAGE''': upstream website
* '''BUGTRACKER''': upstream bug tracker URL if available
* '''LICENSE''': must be accurate and list all applicable licenses
* '''LIC_FILES_CHKSUM''': should if at all possible point to one or more files within the upstream source in order to detect changes on upgrade
 
== do_install ==
 
* Don't use ''cp'' to put files into staging or destination directories, use ''install'' instead.
* Don't use ''mkdir'' to create destination directories, use ''install -d'' instead.
* Modify files after installing them, not before (to ensure do_install can be re-executed)
* Use rm -f to avoid failure in case do_install is re-executed
 
== Ordering and grouping ==
 
* Put the ''inherit'' declaration after the initial variables are set up and before any custom ''do_'' routines. This is flexible as ordering is often important.
* If you define custom ''do_'' routines, keep them in the order of the tasks being executed, that is:
** do_fetch
** do_unpack
** do_patch
** do_configure
** do_compile
** do_install
** do_populate_sysroot
** do_package
 
* There is a standard set of variables often found in a .bb file and the preferred order (to make the file easily readable to seasoned developers) is
** SUMMARY
** DESCRIPTION
** AUTHOR
** HOMEPAGE
** SECTION
** LICENSE
** LIC_FILES_CHKSUM
** DEPENDS
** PROVIDES
** PV
** SRC_URI
** SRCREV
** S
** inherit ...
** build class specific variables, i.e. EXTRA_QMAKEVARS_POST
** task overrides, i.e. do_configure
** PACKAGE_ARCH
** PACKAGES
** FILES
** RDEPENDS
** RRECOMMENDS
** RSUGGESTS
** RPROVIDES
** RCONFLICTS
 
* Package related variables for a given package are often grouped together for clarity.
 
== Version fields ==
 
* Handling PR (revision):
** Remove PR when PV (i.e. the recipe version) increases
** Preserve existing PR values otherwise (or the overall version will decrease which is not desirable)
** Do not specify PR in new recipes
** No need to increase existing values of PR unless there is a change that would not otherwise trigger the appropriate rebuild/re-execution (very rare)
* If the PV changes in such a way that it does not increase with respect to the previous value, you need to increase PE (or set it to "1" if not already set) to ensure package managers will upgrade it correctly
 
== Patches ==
 
Patches (i.e. patch files which are referred to in SRC_URI within recipes) should have a header containing information about where they came from and why they are required. This makes examining patches in future and sending appropriate ones upstream much easier.
 
For further information on patch header formatting, see [[Commit Patch Message Guidelines]].
 
 
= Example Recipe =
 
<pre>
SUMMARY = "X11 Code Viewer"
DESCRIPTION = "Allow viewing of X11 code in a fancy way which allows easier \
              and more productive X11 programming"
AUTHOR = "John Bazz <john.bazz@example.org>"
HOMEPAGE = "http://www.example.org/xcv/"
SECTION = "x11/applications"
LICENSE = "GPL-2.0"
DEPENDS = "libsm libx11 libxext libxaw"
PV = "0.9+git${SRCPV}"
 
# upstream does not yet publish any release so we have to fetch last working version from GIT
SRCREV = "6a5e79ae8a0f4a273a603b2df1742972510d3d8f"
SRC_URI = "git://xcv.example.org/xcv;protocol=http \
          file://toolbar-resize-fix.patch"
 
S = "${WORKDIR}/xcv/"
 
inherit autotools
 
do_configure_prepend() {
    rm ${S}/aclocal.m4
}
 
do_install() {
    install -d ${D}${bindir}
    install -d ${D}${mandir}/man1
 
    install -m 0755 xcv ${D}${bindir}/ 
    install -m 0644 xcv.1.gz ${D}${mandir}/man1/
}
 
RDEPENDS_${PN} = "shared-mime-info"
RRECOMMENDS_${PN} = "ctags"
RCONFLICTS_${PN} = "xcv2"
</pre>
 
[[Category:Policy]]

Latest revision as of 16:54, 30 August 2023

This page has moved to the Yocto Documentation Contributors Guide

Retrieved from "https://www.openembedded.org/w/index.php?title=Styleguide&oldid=11139"