diff options
Diffstat (limited to 'documentation/ref-manual/eclipse/html/poky-ref-manual/license-flag-matching.html')
-rw-r--r-- | documentation/ref-manual/eclipse/html/poky-ref-manual/license-flag-matching.html | 91 |
1 files changed, 0 insertions, 91 deletions
diff --git a/documentation/ref-manual/eclipse/html/poky-ref-manual/license-flag-matching.html b/documentation/ref-manual/eclipse/html/poky-ref-manual/license-flag-matching.html deleted file mode 100644 index 8909689399..0000000000 --- a/documentation/ref-manual/eclipse/html/poky-ref-manual/license-flag-matching.html +++ /dev/null | |||
@@ -1,91 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>3.4.2.1. License Flag Matching</title> | ||
5 | <link rel="stylesheet" type="text/css" href="../book.css"> | ||
6 | <meta name="generator" content="DocBook XSL Stylesheets V1.76.1"> | ||
7 | <link rel="home" href="index.html" title="The Yocto Project Reference Manual"> | ||
8 | <link rel="up" href="enabling-commercially-licensed-recipes.html" title="3.4.2. Enabling Commercially Licensed Recipes"> | ||
9 | <link rel="prev" href="enabling-commercially-licensed-recipes.html" title="3.4.2. Enabling Commercially Licensed Recipes"> | ||
10 | <link rel="next" href="other-variables-related-to-commercial-licenses.html" title="3.4.2.2. Other Variables Related to Commercial Licenses"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.4.2.1. License Flag Matching"> | ||
13 | <div class="titlepage"><div><div><h4 class="title"> | ||
14 | <a name="license-flag-matching"></a>3.4.2.1. License Flag Matching</h4></div></div></div> | ||
15 | <p> | ||
16 | The definition of 'matching' in reference to a | ||
17 | recipe's <code class="filename">LICENSE_FLAGS</code> setting is simple. | ||
18 | However, some things exist that you should know about in order to | ||
19 | correctly and effectively use it. | ||
20 | </p> | ||
21 | <p> | ||
22 | Before a flag | ||
23 | defined by a particular recipe is tested against the | ||
24 | contents of the <code class="filename">LICENSE_FLAGS_WHITELIST</code> variable, the | ||
25 | string <code class="filename">_${PN}</code> (with | ||
26 | <a class="link" href="ref-variables-glos.html#var-PN" title="PN"><code class="filename">PN</code></a> expanded of course) is | ||
27 | appended to the flag, thus automatically making each | ||
28 | <code class="filename">LICENSE_FLAGS</code> value recipe-specific. | ||
29 | That string is | ||
30 | then matched against the whitelist. | ||
31 | So if you specify <code class="filename">LICENSE_FLAGS = "commercial"</code> in recipe | ||
32 | "foo" for example, the string <code class="filename">"commercial_foo"</code> | ||
33 | would normally be what is specified in the whitelist in order for it to | ||
34 | match. | ||
35 | </p> | ||
36 | <p> | ||
37 | You can broaden the match by | ||
38 | putting any "_"-separated beginning subset of a | ||
39 | <code class="filename">LICENSE_FLAGS</code> flag in the whitelist, which will also | ||
40 | match. | ||
41 | For example, simply specifying "commercial" in | ||
42 | the whitelist would match any expanded <code class="filename">LICENSE_FLAGS</code> | ||
43 | definition starting with "commercial" such as | ||
44 | "commercial_foo" and "commercial_bar", which are the | ||
45 | strings that would be automatically generated for | ||
46 | hypothetical "foo" and "bar" recipes assuming those | ||
47 | recipes had simply specified the following: | ||
48 | </p> | ||
49 | <pre class="literallayout"> | ||
50 | LICENSE_FLAGS = "commercial" | ||
51 | </pre> | ||
52 | <p> | ||
53 | </p> | ||
54 | <p> | ||
55 | Broadening the match allows for a range of specificity for the items | ||
56 | in the whitelist, from more general to perfectly | ||
57 | specific. | ||
58 | So you have the choice of exhaustively | ||
59 | enumerating each license flag in the whitelist to | ||
60 | allow only those specific recipes into the image, or | ||
61 | of using a more general string to pick up anything | ||
62 | matching just the first component or components of the specified | ||
63 | string. | ||
64 | </p> | ||
65 | <p> | ||
66 | This scheme works even if the flag already | ||
67 | has <code class="filename">_${PN}</code> appended - the extra <code class="filename">_${PN}</code> is | ||
68 | redundant, but does not affect the outcome. | ||
69 | For example, a license flag of "commercial_1.2_foo" would | ||
70 | turn into "commercial_1.2_foo_foo" and would match | ||
71 | both the general "commercial" and the specific | ||
72 | "commercial_1.2_foo", as expected. | ||
73 | The flag would also match | ||
74 | "commercial_1.2_foo_foo" and "commercial_1.2", which | ||
75 | does not make much sense regarding use in the whitelist. | ||
76 | </p> | ||
77 | <p> | ||
78 | For a versioned string, you could instead specify | ||
79 | "commercial_foo_1.2", which would turn into | ||
80 | "commercial_foo_1.2_foo". | ||
81 | And, as expected, this flag allows | ||
82 | you to pick up this package along with | ||
83 | anything else "commercial" when you specify "commercial" | ||
84 | in the whitelist. | ||
85 | Or, the flag allows you to pick up this package along with anything "commercial_foo" | ||
86 | regardless of version when you use "commercial_foo" in the whitelist. | ||
87 | Finally, you can be completely specific about the package and version and specify | ||
88 | "commercial_foo_1.2" package and version. | ||
89 | </p> | ||
90 | </div></body> | ||
91 | </html> | ||