diff options
| author | Robert P. J. Day <rpjday@crashcourse.ca> | 2025-07-09 14:16:54 -0400 |
|---|---|---|
| committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2025-07-28 14:51:50 +0100 |
| commit | 6003a9615dc4cc8b02912815a3d785299d01fe25 (patch) | |
| tree | 5e379d207795ea9f734f58d1f7e51eb8b6677ad3 | |
| parent | 18c6ff0ae12f6b48bc53c8230bf06e01a8d8681d (diff) | |
| download | poky-6003a9615dc4cc8b02912815a3d785299d01fe25.tar.gz | |
bitbake: bitbake: clarify significance of "include_all" directive
Rewrite the include and include_all sections to drive home the fact
that the include_all directive is relevant in only very specific
cases, and not something developers should expect to use in normal
operation.
(Bitbake rev: 4b3bfe70d02cc1c11972357e2dc595acc75056e5)
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
| -rw-r--r-- | bitbake/doc/bitbake-user-manual/bitbake-user-manual-metadata.rst | 69 |
1 files changed, 39 insertions, 30 deletions
diff --git a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-metadata.rst b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-metadata.rst index f60a9d8312..1042c65d89 100644 --- a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-metadata.rst +++ b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-metadata.rst | |||
| @@ -874,58 +874,67 @@ becomes a no-op. | |||
| 874 | ``include`` Directive | 874 | ``include`` Directive |
| 875 | --------------------- | 875 | --------------------- |
| 876 | 876 | ||
| 877 | BitBake understands the ``include`` directive. This directive causes | 877 | The ``include`` directive causes BitBake to parse a given file, |
| 878 | BitBake to parse whatever file you specify, and to insert that file at | 878 | and to include that file's contents at the location of the |
| 879 | that location. The directive is much like its equivalent in Make except | 879 | ``include`` statement. This directive is similar to its equivalent |
| 880 | that if the path specified on the include line is a relative path, | 880 | in Make, except that if the path specified on the BitBake ``include`` |
| 881 | BitBake locates the first file it can find within :term:`BBPATH`. | 881 | line is a relative path, BitBake will search for it on the path designated |
| 882 | 882 | by :term:`BBPATH` and will include *only the first matching file*. | |
| 883 | The include directive is a more generic method of including | 883 | |
| 884 | The ``include`` directive is a more generic method of including | ||
| 884 | functionality as compared to the :ref:`inherit <bitbake-user-manual/bitbake-user-manual-metadata:\`\`inherit\`\` directive>` | 885 | functionality as compared to the :ref:`inherit <bitbake-user-manual/bitbake-user-manual-metadata:\`\`inherit\`\` directive>` |
| 885 | directive, which is restricted to class (i.e. ``.bbclass``) files. The | 886 | directive, which is restricted to class (i.e. ``.bbclass``) files. The |
| 886 | include directive is applicable for any other kind of shared or | 887 | ``include`` directive is applicable for any other kind of shared or |
| 887 | encapsulated functionality or configuration that does not suit a | 888 | encapsulated functionality or configuration that does not suit a |
| 888 | ``.bbclass`` file. | 889 | ``.bbclass`` file. |
| 889 | 890 | ||
| 890 | As an example, suppose you needed a recipe to include some self-test | 891 | For example, if you needed a recipe to include some self-test definitions, |
| 891 | definitions:: | 892 | you might write:: |
| 892 | 893 | ||
| 893 | include test_defs.inc | 894 | include test_defs.inc |
| 894 | 895 | ||
| 896 | The ``include`` directive does not produce an error if the specified file | ||
| 897 | cannot be found. If the included file *must* exist, then you should use | ||
| 898 | use :ref:`require <require-inclusion>` instead, which will generate an error | ||
| 899 | if the file cannot be found. | ||
| 900 | |||
| 895 | .. note:: | 901 | .. note:: |
| 896 | 902 | ||
| 897 | The include directive does not produce an error when the file cannot be | 903 | Note well that the ``include`` directive will include the first matching |
| 898 | found. Consequently, it is recommended that if the file you are including is | 904 | file and nothing further (which is almost always the behaviour you want). |
| 899 | expected to exist, you should use :ref:`require <require-inclusion>` instead | 905 | If you need to include all matching files, you need to use the |
| 900 | of include . Doing so makes sure that an error is produced if the file cannot | 906 | ``include_all`` directive, explained below. |
| 901 | be found. | ||
| 902 | 907 | ||
| 903 | ``include_all`` Directive | 908 | ``include_all`` Directive |
| 904 | ------------------------- | 909 | ------------------------- |
| 905 | 910 | ||
| 906 | The ``include_all`` directive works like the :ref:`include | 911 | The ``include_all`` directive works like the :ref:`include |
| 907 | <bitbake-user-manual/bitbake-user-manual-metadata:\`\`include\`\` directive>` | 912 | <bitbake-user-manual/bitbake-user-manual-metadata:\`\`include\`\` directive>` |
| 908 | directive but will include all of the files that match the specified path in | 913 | directive but will include *all* of the files that match the specified path in |
| 909 | the enabled layers (layers part of :term:`BBLAYERS`). | 914 | the enabled layers (layers part of :term:`BBLAYERS`). |
| 910 | 915 | ||
| 911 | For example, let's say a ``maintainers.inc`` file is present in different layers | 916 | .. note:: |
| 912 | and is conventionally placed in the ``conf/distro/include`` directory of each | ||
| 913 | layer. In that case the ``include_all`` directive can be used to include | ||
| 914 | the ``maintainers.inc`` file for all of these layers:: | ||
| 915 | 917 | ||
| 916 | include_all conf/distro/include/maintainers.inc | 918 | This behaviour is rarely what you want in normal operation, and should |
| 919 | be reserved for only those situations when you explicitly want to parse | ||
| 920 | and include all matching files found across all layers, as the following | ||
| 921 | example shows. | ||
| 917 | 922 | ||
| 918 | In other words, the ``maintainers.inc`` file for each layer is included through | 923 | As a realistic example of this directive, imagine that all of your active |
| 919 | the :ref:`include <bitbake-user-manual/bitbake-user-manual-metadata:\`\`include\`\` directive>` | 924 | layers contain a file ``conf/distro/include/maintainers.inc``, containing |
| 920 | directive. | 925 | maintainer information for the recipes in that layer, and you wanted to |
| 926 | collect all of the content from all of those files across all of those layers. | ||
| 927 | You could use the statement:: | ||
| 928 | |||
| 929 | include_all conf/distro/include/maintainers.inc | ||
| 921 | 930 | ||
| 922 | BitBake will iterate through the colon-separated :term:`BBPATH` list to look for | 931 | In this case, BitBake will iterate through all of the directories in |
| 923 | matching files to include, from left to right. As a consequence, matching files | 932 | the colon-separated :term:`BBPATH` (from left to right) and collect the |
| 924 | are included in that order. | 933 | contents of all matching files, so you end up with the maintainer |
| 934 | information of all of your active layers, not just the first one. | ||
| 925 | 935 | ||
| 926 | As the ``include_all`` directive uses the :ref:`include | 936 | As the ``include_all`` directive uses the ``include`` directive in the |
| 927 | <bitbake-user-manual/bitbake-user-manual-metadata:\`\`include\`\` directive>` | 937 | background, as with ``include``, no error is produced if no files are matched. |
| 928 | directive in the background, no error is produced if no files are matched. | ||
| 929 | 938 | ||
| 930 | .. _require-inclusion: | 939 | .. _require-inclusion: |
| 931 | 940 | ||
