diff options
Diffstat (limited to 'documentation/dev-manual/layers.rst')
-rw-r--r-- | documentation/dev-manual/layers.rst | 90 |
1 files changed, 90 insertions, 0 deletions
diff --git a/documentation/dev-manual/layers.rst b/documentation/dev-manual/layers.rst index 91889bd0ae..89c8466933 100644 --- a/documentation/dev-manual/layers.rst +++ b/documentation/dev-manual/layers.rst | |||
@@ -644,6 +644,96 @@ variable and append the layer's root name:: | |||
644 | order of ``.conf`` or ``.bbclass`` files. Future versions of BitBake | 644 | order of ``.conf`` or ``.bbclass`` files. Future versions of BitBake |
645 | might address this. | 645 | might address this. |
646 | 646 | ||
647 | Providing Global-level Configurations With Your Layer | ||
648 | ----------------------------------------------------- | ||
649 | |||
650 | When creating a layer, you may need to define configurations that should take | ||
651 | effect globally in your build environment when the layer is part of the build. | ||
652 | The ``layer.conf`` file is a :term:`configuration file` that affects the build | ||
653 | system globally, so it is a candidate for this use-case. | ||
654 | |||
655 | .. warning:: | ||
656 | |||
657 | Providing unconditional global level configuration from the ``layer.conf`` | ||
658 | file is *not* a good practice, and should be avoided. For this reason, the | ||
659 | section :ref:`ref-conditional-layer-confs` below shows how the ``layer.conf`` | ||
660 | file can be used to provide configurations only if a certain condition is | ||
661 | met. | ||
662 | |||
663 | For example, if your layer provides a Linux kernel recipe named | ||
664 | ``linux-custom``, you may want to make :term:`PREFERRED_PROVIDER_virtual/kernel | ||
665 | <PREFERRED_PROVIDER>` point to ``linux-custom``:: | ||
666 | |||
667 | PREFERRED_PROVIDER_virtual/kernel = "linux-custom" | ||
668 | |||
669 | This can be defined in the ``layer.conf`` file. If your layer is at the last | ||
670 | position in the :term:`BBLAYERS` list, it will take precedence over previous | ||
671 | ``PREFERRED_PROVIDER_virtual/kernel`` assignments (unless one is set from a | ||
672 | :term:`configuration file` that is parsed later, such as machine or distro | ||
673 | configuration files). | ||
674 | |||
675 | .. _ref-conditional-layer-confs: | ||
676 | |||
677 | Conditionally Provide Global-level Configurations With Your Layer | ||
678 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | ||
679 | |||
680 | In some cases, your layer may provide global configurations only if some | ||
681 | features it provides are enabled. Since the ``layer.conf`` file is parsed at an | ||
682 | earlier stage in the parsing process, the :term:`DISTRO_FEATURES` and | ||
683 | :term:`MACHINE_FEATURES` variables are not yet available to ``layer.conf``, and | ||
684 | declaring conditional assignments based on these variables is not possible. The | ||
685 | following technique shows a way to bypass this limitation by using the | ||
686 | :term:`USER_CLASSES` variable and a conditional ``require`` command. | ||
687 | |||
688 | In the following steps, let's assume our layer is named ``meta-mylayer`` and | ||
689 | that this layer defines a custom :ref:`distro feature <ref-features-distro>` | ||
690 | named ``mylayer-kernel``. We will set the :term:`PREFERRED_PROVIDER` variable | ||
691 | for the kernel only if our feature ``mylayer-kernel`` is part of the | ||
692 | :term:`DISTRO_FEATURES`: | ||
693 | |||
694 | #. Create an include file in the directory | ||
695 | ``meta-mylayer/conf/distro/include/``, for example a file named | ||
696 | ``mylayer-kernel-provider.inc`` that sets the kernel provider to | ||
697 | ``linux-custom``:: | ||
698 | |||
699 | PREFERRED_PROVIDER_virtual/kernel = "linux-custom" | ||
700 | |||
701 | #. Provide a path to this include file in your ``layer.conf``:: | ||
702 | |||
703 | META_MYLAYER_KERNEL_PROVIDER_PATH = "${LAYERDIR}/conf/distro/include/mylayer-kernel-provider.inc" | ||
704 | |||
705 | #. Create a new class in ``meta-mylayer/classes-global/``, for example a class | ||
706 | ``meta-mylayer-cfg.bbclass``. Make it conditionally require the file | ||
707 | ``mylayer-kernel-provider.inc`` defined above, using the variable | ||
708 | ``META_MYLAYER_KERNEL_PROVIDER_PATH`` defined in ``layer.conf``:: | ||
709 | |||
710 | require ${@bb.utils.contains('DISTRO_FEATURES', 'mylayer-kernel', '${META_MYLAYER_KERNEL_PROVIDER_PATH}', '', d)} | ||
711 | |||
712 | For details on the ``bb.utils.contains`` function, see its definition in | ||
713 | :bitbake_git:`lib/bb/utils.py </tree/lib/bb/utils.py>`. | ||
714 | |||
715 | .. note:: | ||
716 | |||
717 | The ``require`` command is designed to not fail if the function | ||
718 | ``bb.utils.contains`` returns an empty string. | ||
719 | |||
720 | #. Back to your ``layer.conf`` file, add the class ``meta-mylayer-cfg`` class to | ||
721 | the :term:`USER_CLASSES` variable:: | ||
722 | |||
723 | USER_CLASSES:append = " meta-mylayer-cfg" | ||
724 | |||
725 | This will add the class ``meta-mylayer-cfg`` to the list of classes to | ||
726 | globally inherit. Since the ``require`` command is conditional in | ||
727 | ``meta-mylayer-cfg.bbclass``, even though inherited the class will have no | ||
728 | effect unless the feature ``mylayer-kernel`` is enabled through | ||
729 | :term:`DISTRO_FEATURES`. | ||
730 | |||
731 | This technique can also be used for :ref:`Machine features | ||
732 | <ref-features-machine>` by following the same steps. Though not mandatory, it is | ||
733 | recommended to put include files for :term:`DISTRO_FEATURES` in your layer's | ||
734 | ``conf/distro/include`` and the ones for :term:`MACHINE_FEATURES` in your | ||
735 | layer's ``conf/machine/include``. | ||
736 | |||
647 | Managing Layers | 737 | Managing Layers |
648 | =============== | 738 | =============== |
649 | 739 | ||