diff options
| -rw-r--r-- | documentation/ref-manual/technical-details.xml | 66 |
1 files changed, 39 insertions, 27 deletions
diff --git a/documentation/ref-manual/technical-details.xml b/documentation/ref-manual/technical-details.xml index 1f3901358b..d66d7050a1 100644 --- a/documentation/ref-manual/technical-details.xml +++ b/documentation/ref-manual/technical-details.xml | |||
| @@ -902,48 +902,60 @@ | |||
| 902 | <title>License Flag Matching</title> | 902 | <title>License Flag Matching</title> |
| 903 | 903 | ||
| 904 | <para> | 904 | <para> |
| 905 | The definition of "matching" in reference to a | 905 | In general, license flag matching is simple. |
| 906 | recipe's <filename>LICENSE_FLAGS</filename> setting is simple. | 906 | However, understanding some concepts will help you |
| 907 | However, some things exist that you should know about in order to | 907 | correctly and effectively use matching. |
| 908 | correctly and effectively use it. | ||
| 909 | </para> | 908 | </para> |
| 910 | 909 | ||
| 911 | <para> | 910 | <para> |
| 912 | Before a flag | 911 | Before a flag |
| 913 | defined by a particular recipe is tested against the | 912 | defined by a particular recipe is tested against the |
| 914 | contents of the <filename>LICENSE_FLAGS_WHITELIST</filename> variable, the | 913 | contents of the <filename>LICENSE_FLAGS_WHITELIST</filename> variable, the |
| 915 | string <filename>_${PN}</filename> (with | 914 | expanded string <filename>_${PN}</filename> is |
| 916 | <link linkend='var-PN'><filename>PN</filename></link> expanded of course) is | 915 | appended to the flag. |
| 917 | appended to the flag, thus automatically making each | 916 | This expansion makes each <filename>LICENSE_FLAGS</filename> |
| 918 | <filename>LICENSE_FLAGS</filename> value recipe-specific. | 917 | value recipe-specific. |
| 919 | That string is | 918 | After expansion, the string is then matched against the |
| 920 | then matched against the whitelist. | 919 | whitelist. |
| 921 | So if you specify <filename>LICENSE_FLAGS = "commercial"</filename> in recipe | 920 | Thus, specifying <filename>LICENSE_FLAGS = "commercial"</filename> |
| 922 | "foo" for example, the string <filename>"commercial_foo"</filename> | 921 | in recipe "foo" for example, results in the string |
| 923 | would normally be what is specified in the whitelist in order for it to | 922 | <filename>"commercial_foo"</filename>. |
| 924 | match. | 923 | And that string would normally be appears in the whitelist |
| 924 | in order for a match to occur. | ||
| 925 | </para> | 925 | </para> |
| 926 | 926 | ||
| 927 | <para> | 927 | <para> |
| 928 | You can broaden the match by | 928 | Judicious use of the <filename>LICENSE_FLAGS</filename> |
| 929 | putting any "_"-separated beginning subset of a | 929 | strings and the contents of the |
| 930 | <filename>LICENSE_FLAGS</filename> flag in the whitelist, which will also | 930 | <filename>LICENSE_FLAGS_WHITELIST</filename> variable |
| 931 | match. | 931 | allows you a lot of flexibility for matching license |
| 932 | For example, simply specifying "commercial" in | 932 | flags. |
| 933 | the whitelist would match any expanded <filename>LICENSE_FLAGS</filename> | 933 | For example, you can broaden the matching capabilities by |
| 934 | definition starting with "commercial" such as | 934 | using string subsets from the <filename>LICENSE_FLAGS</filename> |
| 935 | "commercial_foo" and "commercial_bar", which are the | 935 | variables in the whitelist. |
| 936 | strings that would be automatically generated for | 936 | <note>Be sure to use the part of the expanded |
| 937 | hypothetical "foo" and "bar" recipes assuming those | 937 | string that precedes |
| 938 | recipes had simply specified the following: | 938 | the underscore character (e.g. |
| 939 | <filename>usethispart_1.3</filename>, | ||
| 940 | <filename>usethispart_1.4</filename>, and so forth). | ||
| 941 | </note> | ||
| 942 | For example, simply specifying the string "commercial" in | ||
| 943 | the whitelist matches any expanded | ||
| 944 | <filename>LICENSE_FLAGS</filename> definition that starts with | ||
| 945 | the string "commercial" such as "commercial_foo" and | ||
| 946 | "commercial_bar", which are the strings the build system | ||
| 947 | automatically generates for hypothetical recipes named | ||
| 948 | "foo" and "bar" assuming those recipes simply specify the | ||
| 949 | following: | ||
| 939 | <literallayout class='monospaced'> | 950 | <literallayout class='monospaced'> |
| 940 | LICENSE_FLAGS = "commercial" | 951 | LICENSE_FLAGS = "commercial" |
| 941 | </literallayout> | 952 | </literallayout> |
| 942 | </para> | 953 | </para> |
| 943 | 954 | ||
| 944 | <para> | 955 | <para> |
| 945 | Broadening the match allows for a range of specificity for the items | 956 | Judicious use of the strings with the |
| 946 | in the whitelist, from more general to perfectly | 957 | <filename>LICENSE_FLAGS</filename> variable and the Broadening the match allows for a range of specificity for the |
| 958 | items in the whitelist, from more general to perfectly | ||
| 947 | specific. | 959 | specific. |
| 948 | So you have the choice of exhaustively | 960 | So you have the choice of exhaustively |
| 949 | enumerating each license flag in the whitelist to | 961 | enumerating each license flag in the whitelist to |
