ref-manual: Edits to the license flag matching section.

Partial edits.

(From yocto-docs rev: 32c1d40eff9a3e27d5ec09bde57e2c344bb2ded9)

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-26 16:54:32 -07:00 committed by Richard Purdie
parent 4b1833f881
commit 30cdf93d0c
1 changed files with 39 additions and 27 deletions

View File

@ -902,48 +902,60 @@
<title>License Flag Matching</title>
<para>
The definition of "matching" in reference to a
recipe's <filename>LICENSE_FLAGS</filename> setting is simple.
However, some things exist that you should know about in order to
correctly and effectively use it.
In general, license flag matching is simple.
However, understanding some concepts will help you
correctly and effectively use matching.
</para>
<para>
Before a flag
defined by a particular recipe is tested against the
contents of the <filename>LICENSE_FLAGS_WHITELIST</filename> variable, the
string <filename>_${PN}</filename> (with
<link linkend='var-PN'><filename>PN</filename></link> expanded of course) is
appended to the flag, thus automatically making each
<filename>LICENSE_FLAGS</filename> value recipe-specific.
That string is
then matched against the whitelist.
So if you specify <filename>LICENSE_FLAGS = "commercial"</filename> in recipe
"foo" for example, the string <filename>"commercial_foo"</filename>
would normally be what is specified in the whitelist in order for it to
match.
expanded string <filename>_${PN}</filename> is
appended to the flag.
This expansion makes each <filename>LICENSE_FLAGS</filename>
value recipe-specific.
After expansion, the string is then matched against the
whitelist.
Thus, specifying <filename>LICENSE_FLAGS = "commercial"</filename>
in recipe "foo" for example, results in the string
<filename>"commercial_foo"</filename>.
And that string would normally be appears in the whitelist
in order for a match to occur.
</para>
<para>
You can broaden the match by
putting any "_"-separated beginning subset of a
<filename>LICENSE_FLAGS</filename> flag in the whitelist, which will also
match.
For example, simply specifying "commercial" in
the whitelist would match any expanded <filename>LICENSE_FLAGS</filename>
definition starting with "commercial" such as
"commercial_foo" and "commercial_bar", which are the
strings that would be automatically generated for
hypothetical "foo" and "bar" recipes assuming those
recipes had simply specified the following:
Judicious use of the <filename>LICENSE_FLAGS</filename>
strings and the contents of the
<filename>LICENSE_FLAGS_WHITELIST</filename> variable
allows you a lot of flexibility for matching license
flags.
For example, you can broaden the matching capabilities by
using string subsets from the <filename>LICENSE_FLAGS</filename>
variables in the whitelist.
<note>Be sure to use the part of the expanded
string that precedes
the underscore character (e.g.
<filename>usethispart_1.3</filename>,
<filename>usethispart_1.4</filename>, and so forth).
</note>
For example, simply specifying the string "commercial" in
the whitelist matches any expanded
<filename>LICENSE_FLAGS</filename> definition that starts with
the string "commercial" such as "commercial_foo" and
"commercial_bar", which are the strings the build system
automatically generates for hypothetical recipes named
"foo" and "bar" assuming those recipes simply specify the
following:
<literallayout class='monospaced'>
LICENSE_FLAGS = "commercial"
</literallayout>
</para>
<para>
Broadening the match allows for a range of specificity for the items
in the whitelist, from more general to perfectly
Judicious use of the strings with the
<filename>LICENSE_FLAGS</filename> variable and the Broadening the match allows for a range of specificity for the
items in the whitelist, from more general to perfectly
specific.
So you have the choice of exhaustively
enumerating each license flag in the whitelist to