Styleguide - Revision history

JPEWhacker at 16:54, 30 August 2023

2023-08-30T16:54:15Z

← Older revision		Revision as of 16:54, 30 August 2023
Line 1:		Line 1:
	This page has moved to the [https://docs.yoctoproject.org/~~doc~~/contributor-guide/recipe-style-guide.html Yocto Documentation Contributors Guide]		This page has moved to the [https://docs.yoctoproject.org/dev/contributor-guide/recipe-style-guide.html Yocto Documentation Contributors Guide]

JPEWhacker: Moved to YP docs

2023-08-30T15:25:29Z

Moved to YP docs

Show changes

Twoerner: add BUGTRACKER into the standard variable /function order list

2018-05-24T18:02:25Z

add BUGTRACKER into the standard variable /function order list

← Older revision		Revision as of 18:02, 24 May 2018
Line 73:		Line 73:
	** AUTHOR		** AUTHOR
	** HOMEPAGE		** HOMEPAGE
			** BUGTRACKER
	** SECTION		** SECTION
	** LICENSE		** LICENSE

Twoerner: add PACKAGECONFIG and BBCLASSEXTEND to variable layout section. add EXTRA_OECONF as an additional example of "build class specific variables"

2018-05-24T17:22:54Z

add PACKAGECONFIG and BBCLASSEXTEND to variable layout section. add EXTRA_OECONF as an additional example of "build class specific variables"

← Older revision		Revision as of 17:22, 24 May 2018
Line 83:		Line 83:
	** S		** S
	** inherit ...		** inherit ...
	** build class specific variables, i.e. EXTRA_QMAKEVARS_POST		** PACKAGECONFIG
			** build class specific variables, i.e. EXTRA_QMAKEVARS_POST, EXTRA_OECONF
	** task overrides, i.e. do_configure		** task overrides, i.e. do_configure
	** PACKAGE_ARCH		** PACKAGE_ARCH
Line 93:		Line 94:
	** RPROVIDES		** RPROVIDES
	** RCONFLICTS		** RCONFLICTS
			** BBCLASSEXTEND

	* Package related variables for a given package are often grouped together for clarity.		* Package related variables for a given package are often grouped together for clarity.

PaulEggleton: Explicitly link to Versioning Policy page

2014-06-05T12:59:07Z

Explicitly link to Versioning Policy page

← Older revision		Revision as of 12:59, 5 June 2014
Line 5:		Line 5:
	= Naming Conventions =		= Naming Conventions =

	[[Versioning Policy~~\|Use $packagename_$version.bb~~]]		* Generally, name recipes <packagename>_<version>.bb
			* See also [[Versioning Policy]]

	= Format Guidelines =		= Format Guidelines =
Line 103:		Line 104:
	** 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)		** 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		* 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

			See also [[Versioning Policy]]

	== Patches ==		== Patches ==

PaulEggleton: Clarify oe-stylize section and move it lower down, since it's not as useful as it was in the OE-Classic days

2014-06-05T12:45:29Z

Clarify oe-stylize section and move it lower down, since it's not as useful as it was in the OE-Classic days

← Older revision		Revision as of 12:45, 5 June 2014
Line 30:		Line 30:
	</li>		</li>
	</ul>		</ul>

	~~= Style Checking tools =~~

	~~Please run ./contrib/oe-stylize.py on your recipes before submitting them.~~

	= Style Guidelines =		= Style Guidelines =
Line 119:		Line 115:
	* Avoid custom do_configure for autotooled projects - the default provided by autotools.bbclass should work for almost all cases		* Avoid custom do_configure for autotooled projects - the default provided by autotools.bbclass should work for almost all cases
	* pkgconfig .pc files should be correct and not need manual mangling		* pkgconfig .pc files should be correct and not need manual mangling

			= Style Checking tools =

			You can run contrib/oe-stylize.py from meta-oe on your recipes before submitting them; however it is not necessarily up-to-date with all current style conventions. This page should be considered the canonical reference.

	= Example Recipe =		= Example Recipe =

PaulEggleton: /* Format Guidelines */

2014-06-05T12:43:16Z

Format Guidelines

← Older revision		Revision as of 12:43, 5 June 2014
Line 18:		Line 18:
	<li>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)</li>		<li>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)</li>
	<li>Splitting of long list values (such as SRC_URI) over multiple lines, and indenting the second line onwards is desirable:<ul>		<li>Splitting of long list values (such as SRC_URI) over multiple lines, and indenting the second line onwards is desirable:<ul>
	<li>For values split over multiple lines, indent successive lines up to the level of the start of the value on the first line, and have the quote on its own line:<pre>		<li>For values split over multiple lines, indent successive lines up to the level of the start of the value on the first line, and have the final closing quote on its own line:<pre>
	FOO = "\		FOO = "\
	bar \		bar \

PaulEggleton at 12:42, 5 June 2014

2014-06-05T12:42:54Z

← Older revision		Revision as of 12:42, 5 June 2014
Line 22:		Line 22:
	bar \		bar \
	done \		done \
	"</pre></li>		"</pre></li>
	<li>Some layers prefer to use four-space indentation on sucessive lines and prefer the closing quote as the first character:<pre>		<li>Some layers prefer to use four-space indentation on sucessive lines and prefer the closing quote as the first character:<pre>
	FOO = "\		FOO = "\

PaulEggleton: Remove erroneous one-space indent with new formatting

2014-06-05T12:42:30Z

Remove erroneous one-space indent with new formatting

← Older revision		Revision as of 12:42, 5 June 2014
Line 19:		Line 19:
	<li>Splitting of long list values (such as SRC_URI) over multiple lines, and indenting the second line onwards is desirable:<ul>		<li>Splitting of long list values (such as SRC_URI) over multiple lines, and indenting the second line onwards is desirable:<ul>
	<li>For values split over multiple lines, indent successive lines up to the level of the start of the value on the first line, and have the quote on its own line:<pre>		<li>For values split over multiple lines, indent successive lines up to the level of the start of the value on the first line, and have the quote on its own line:<pre>
	FOO = "\		FOO = "\
	bar \		bar \
	done \		done \
	"</pre></li>		"</pre></li>
	<li>Some layers prefer to use four-space indentation on sucessive lines and prefer the closing quote as the first character:<pre>		<li>Some layers prefer to use four-space indentation on sucessive lines and prefer the closing quote as the first character:<pre>
	FOO = "\		FOO = "\
	bar \		bar \
	done \		done \
	"</pre></li></ul>		"</pre></li></ul>
	</li>		</li>
	</ul>		</ul>

PaulEggleton: Format formatting list more appropriately

2014-06-05T11:28:37Z

Format formatting list more appropriately

← Older revision		Revision as of 11:28, 5 June 2014
Line 9:		Line 9:
	= Format Guidelines =		= Format Guidelines =

	* The correct spacing for a variable assignment is FOO = "BAR".		<ul>
	* Use quotes on the right hand side of assignments: FOO = "BAR"		<li>The correct spacing for a variable assignment is FOO = "BAR".</li>
	* No spaces are allowed behind the line continuation symbol (\)		<li>Use quotes on the right hand side of assignments: FOO = "BAR"</li>
	* Comments are allowed using the '#' character at the beginning of a line, but you cannot use a comment within a continuation.		<li>No spaces are allowed behind the line continuation symbol (\)</li>
	* Use spaces for indentation as developers tends to use different amount of spaces per one tab.		<li>Comments are allowed using the '#' character at the beginning of a line, but you cannot use a comment within a continuation.</li>
	* Python functions must be four space indented - no tabs.		<li>Use spaces for indentation as developers tends to use different amount of spaces per one tab.</li>
	* 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)		<li>Python functions must be four space indented - no tabs.</li>
	* Indentation of ~~multiline variables~~ such as SRC_URI is ~~desireable.~~		<li>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)</li>
	* For values split over multiple lines, indent successive lines up to the level of the start of the value on the first line, and have the quote on its own line:		<li>Splitting of long list values (such as SRC_URI) over multiple lines, and indenting the second line onwards is desirable:<ul>
			<li>For values split over multiple lines, indent successive lines up to the level of the start of the value on the first line, and have the quote on its own line:<pre>
	FOO = "\		FOO = "\
	bar \		bar \
	done \		done \
	"		"</pre></li>
	* Some layers prefer to use four-space indentation on sucessive lines and prefer the closing quote as the first character:		<li>Some layers prefer to use four-space indentation on sucessive lines and prefer the closing quote as the first character:<pre>
	FOO = "\		FOO = "\
	bar \		bar \
	done \		done \
	"		"</pre></li></ul>
			</li>
			</ul>

	= Style Checking tools =		= Style Checking tools =