diff options
author | Timo Mueller <timo.mueller@bmw-carit.de> | 2013-02-08 09:16:33 -0600 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2013-02-14 17:25:35 +0000 |
commit | a41a805500cab281fba15bd8e5d3e60b88d0d4be (patch) | |
tree | 9973678912b57cfdef5b1f9676794a556b4d8966 /documentation/ref-manual/eclipse/html/poky-ref-manual/license-flag-matching.html | |
parent | 768152340898cbb9faed6e8865a4e35c69833230 (diff) | |
download | poky-a41a805500cab281fba15bd8e5d3e60b88d0d4be.tar.gz |
documentation: Part 1 of 2 updates to integrating docs to Eclipse help.
Hi,
the generation of eclipse help files has been merged from the timo
branch to the master. Since the creation of the timo branch there have
been some changes to the master branch (e.g. new documentation,
renamed documentation).
This patch set does some cleanup for the renamed documentation and
adds eclipse help generation support to the new documentation.
01: Removes the 'the' from the document titles
02..04: Cleanup obsolete artifacts resulting from the merge
05..08: Add eclipse help generation for ref-manual
09..13: Add eclipse help generation for kernel-dev
14..18: Add eclipse help generation for profile-manual
Best regards,
Timo
This patch set originally contained 18 patches. I (Scott Rifenbark)
had to push these changes as two parts. This is the first part.
It does not include creation of the three cusomization files.
(From yocto-docs rev: 9b1889f6e31ee70dae704fa08763fb9196616dad)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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> | ||