mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-09-19 09:49:33 +02:00
Code Issues Packages Projects Releases Wiki Activity

ref-manual: rewrite of license flags matching section.

Browse Source 
This whole section was very complicated and difficult to follow.
I have rewritten it to clear it up.

(From yocto-docs rev: 6ad1828eaa3e91b850696590cc732485a52f4cb6)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Scott Rifenbark
2013-03-27 08:11:41 -07:00
committed by Richard Purdie
parent 30cdf93d0c
commit cf6887d914
1 changed files with 83 additions and 73 deletions
Download Patch File Download Diff File Expand all files Collapse all files

110
documentation/ref-manual/technical-details.xml
View File

@@ -902,7 +902,19 @@
<title>License Flag Matching</title> <title>License Flag Matching</title>
<para> <para>
In general, license flag matching is simple. License flag matching allows you to control what recipes the
OpenEmbedded build system includes in the build.
Fundamentally, the build system attempts to match
<filename>LICENSE_FLAG</filename> strings found in
recipes against <filename>LICENSE_FLAGS_WHITELIST</filename>
strings found in the whitelist.
A match, causes the build system to include a recipe in the
build, while failure to find a match causes the build system to
exclued a recipe.
</para>
<para>
In general, license flag matching is simple.
However, understanding some concepts will help you However, understanding some concepts will help you
correctly and effectively use matching. correctly and effectively use matching.
</para> </para>
@@ -910,33 +922,31 @@
<para> <para>
Before a flag Before a flag
defined by a particular recipe is tested against the defined by a particular recipe is tested against the
contents of the <filename>LICENSE_FLAGS_WHITELIST</filename> variable, the contents of the whitelist, the expanded string
expanded string <filename>_${PN}</filename> is <filename>_${PN}</filename> is appended to the flag.
appended to the flag.
This expansion makes each <filename>LICENSE_FLAGS</filename> This expansion makes each <filename>LICENSE_FLAGS</filename>
value recipe-specific. value recipe-specific.
After expansion, the string is then matched against the After expansion, the string is then matched against the
whitelist. whitelist.
Thus, specifying <filename>LICENSE_FLAGS = "commercial"</filename> Thus, specifying
in recipe "foo" for example, results in the string <filename>LICENSE_FLAGS = "commercial"</filename>
in recipe "foo", for example, results in the string
<filename>"commercial_foo"</filename>. <filename>"commercial_foo"</filename>.
And that string would normally be appears in the whitelist And, to create a match, that string must appear in the
in order for a match to occur. whitelist.
</para> </para>
<para> <para>
Judicious use of the <filename>LICENSE_FLAGS</filename> Judicious use of the <filename>LICENSE_FLAGS</filename>
strings and the contents of the strings and the contents of the
<filename>LICENSE_FLAGS_WHITELIST</filename> variable <filename>LICENSE_FLAGS_WHITELIST</filename> variable
allows you a lot of flexibility for matching license allows you a lot of flexibility for including or excluding
flags. recipes based on licensing.
For example, you can broaden the matching capabilities by For example, you can broaden the matching capabilities by
using string subsets from the <filename>LICENSE_FLAGS</filename> using license flags string subsets in the whitelist.
variables in the whitelist. <note>When using a string subset, be sure to use the part of
<note>Be sure to use the part of the expanded the expanded string that precedes the appended underscore
string that precedes character (e.g. <filename>usethispart_1.3</filename>,
the underscore character (e.g.
<filename>usethispart_1.3</filename>,
<filename>usethispart_1.4</filename>, and so forth). <filename>usethispart_1.4</filename>, and so forth).
</note> </note>
For example, simply specifying the string "commercial" in For example, simply specifying the string "commercial" in
@@ -950,46 +960,46 @@
<literallayout class='monospaced'> <literallayout class='monospaced'>
LICENSE_FLAGS = "commercial" LICENSE_FLAGS = "commercial"
</literallayout> </literallayout>
Thus, you can choose to exhaustively
enumerate each license flag in the whitelist and
allow only specific recipes into the image, or
you can use a string subset that causes a broader range of
matches to allow a range of recipes into the image.
</para> </para>
<para> <para>
Judicious use of the strings with the This scheme works even if the
<filename>LICENSE_FLAGS</filename> variable and the Broadening the match allows for a range of specificity for the <filename>LICENSE_FLAG</filename> string already
items in the whitelist, from more general to perfectly has <filename>_${PN}</filename> appended.
specific. For example, the build system turns the license flag
So you have the choice of exhaustively "commercial_1.2_foo" into "commercial_1.2_foo_foo" and would
enumerating each license flag in the whitelist to match both the general "commercial" and the specific
allow only those specific recipes into the image, or "commercial_1.2_foo" strings found in the whitelist, as
of using a more general string to pick up anything expected.
matching just the first component or components of the specified
string.
</para> </para>
<para> <para>
This scheme works even if the flag already Here are some other scenarios:
has <filename>_${PN}</filename> appended - the extra <filename>_${PN}</filename> is <itemizedlist>
redundant, but does not affect the outcome. <listitem><para>You can specify a versioned string in the
For example, a license flag of "commercial_1.2_foo" would recipe such as "commercial_foo_1.2" in a "foo" recipe.
turn into "commercial_1.2_foo_foo" and would match The build system expands this string to
both the general "commercial" and the specific "commercial_foo_1.2_foo".
"commercial_1.2_foo", as expected. Combine this license flag with a whitelist that has
The flag would also match the string "commercial" and you match the flag along
"commercial_1.2_foo_foo" and "commercial_1.2", which with any other flag that starts with the string
does not make much sense regarding use in the whitelist. "commercial".</para></listitem>
</para> <listitem><para>Under the same circumstances, you can
use "commercial_foo" in the whitelist and the
<para> build system not only matches "commercial_foo_1.2" but
For a versioned string, you could instead specify also matches any license flag with the string
"commercial_foo_1.2", which would turn into "commercial_foo", regardless of the version.
"commercial_foo_1.2_foo". </para></listitem>
And, as expected, this flag allows <listitem><para>You can be very specific and use both the
you to pick up this package along with package and version parts in the whitelist (e.g.
anything else "commercial" when you specify "commercial" "commercial_foo_1.2") to specifically match a
in the whitelist. versioned recipe.</para></listitem>
Or, the flag allows you to pick up this package along with anything "commercial_foo" </itemizedlist>
regardless of version when you use "commercial_foo" in the whitelist.
Finally, you can be completely specific about the package and version and specify
"commercial_foo_1.2" package and version.
</para> </para>
</section> </section>