92 lines
5.0 KiB
HTML
92 lines
5.0 KiB
HTML
<html>
|
||
<head>
|
||
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
|
||
<title>3.4.2.1. License Flag Matching</title>
|
||
<link rel="stylesheet" type="text/css" href="../book.css">
|
||
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
|
||
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
|
||
<link rel="up" href="enabling-commercially-licensed-recipes.html" title="3.4.2. Enabling Commercially Licensed Recipes">
|
||
<link rel="prev" href="enabling-commercially-licensed-recipes.html" title="3.4.2. Enabling Commercially Licensed Recipes">
|
||
<link rel="next" href="other-variables-related-to-commercial-licenses.html" title="3.4.2.2. Other Variables Related to Commercial Licenses">
|
||
</head>
|
||
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.4.2.1. License Flag Matching">
|
||
<div class="titlepage"><div><div><h4 class="title">
|
||
<a name="license-flag-matching"></a>3.4.2.1. License Flag Matching</h4></div></div></div>
|
||
<p>
|
||
The definition of 'matching' in reference to a
|
||
recipe's <code class="filename">LICENSE_FLAGS</code> setting is simple.
|
||
However, some things exist that you should know about in order to
|
||
correctly and effectively use it.
|
||
</p>
|
||
<p>
|
||
Before a flag
|
||
defined by a particular recipe is tested against the
|
||
contents of the <code class="filename">LICENSE_FLAGS_WHITELIST</code> variable, the
|
||
string <code class="filename">_${PN}</code> (with
|
||
<a class="link" href="ref-variables-glos.html#var-PN" title="PN"><code class="filename">PN</code></a> expanded of course) is
|
||
appended to the flag, thus automatically making each
|
||
<code class="filename">LICENSE_FLAGS</code> value recipe-specific.
|
||
That string is
|
||
then matched against the whitelist.
|
||
So if you specify <code class="filename">LICENSE_FLAGS = "commercial"</code> in recipe
|
||
"foo" for example, the string <code class="filename">"commercial_foo"</code>
|
||
would normally be what is specified in the whitelist in order for it to
|
||
match.
|
||
</p>
|
||
<p>
|
||
You can broaden the match by
|
||
putting any "_"-separated beginning subset of a
|
||
<code class="filename">LICENSE_FLAGS</code> flag in the whitelist, which will also
|
||
match.
|
||
For example, simply specifying "commercial" in
|
||
the whitelist would match any expanded <code class="filename">LICENSE_FLAGS</code>
|
||
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:
|
||
</p>
|
||
<pre class="literallayout">
|
||
LICENSE_FLAGS = "commercial"
|
||
</pre>
|
||
<p>
|
||
</p>
|
||
<p>
|
||
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
|
||
allow only those specific recipes into the image, or
|
||
of using a more general string to pick up anything
|
||
matching just the first component or components of the specified
|
||
string.
|
||
</p>
|
||
<p>
|
||
This scheme works even if the flag already
|
||
has <code class="filename">_${PN}</code> appended - the extra <code class="filename">_${PN}</code> is
|
||
redundant, but does not affect the outcome.
|
||
For example, a license flag of "commercial_1.2_foo" would
|
||
turn into "commercial_1.2_foo_foo" and would match
|
||
both the general "commercial" and the specific
|
||
"commercial_1.2_foo", as expected.
|
||
The flag would also match
|
||
"commercial_1.2_foo_foo" and "commercial_1.2", which
|
||
does not make much sense regarding use in the whitelist.
|
||
</p>
|
||
<p>
|
||
For a versioned string, you could instead specify
|
||
"commercial_foo_1.2", which would turn into
|
||
"commercial_foo_1.2_foo".
|
||
And, as expected, this flag allows
|
||
you to pick up this package along with
|
||
anything else "commercial" when you specify "commercial"
|
||
in the whitelist.
|
||
Or, the flag allows you to pick up this package along with anything "commercial_foo"
|
||
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.
|
||
</p>
|
||
</div></body>
|
||
</html>
|