1.. SPDX-License-Identifier: CC-BY-SA-2.0-UK 2 3***** 4Tasks 5***** 6 7Tasks are units of execution for BitBake. Recipes (``.bb`` files) use 8tasks to complete configuring, compiling, and packaging software. This 9chapter provides a reference of the tasks defined in the OpenEmbedded 10build system. 11 12Normal Recipe Build Tasks 13========================= 14 15The following sections describe normal tasks associated with building a 16recipe. For more information on tasks and dependencies, see the 17":ref:`bitbake-user-manual/bitbake-user-manual-metadata:tasks`" and 18":ref:`bitbake-user-manual/bitbake-user-manual-execution:dependencies`" sections in the 19BitBake User Manual. 20 21.. _ref-tasks-build: 22 23``do_build`` 24------------ 25 26The default task for all recipes. This task depends on all other normal 27tasks required to build a recipe. 28 29.. _ref-tasks-compile: 30 31``do_compile`` 32-------------- 33 34Compiles the source code. This task runs with the current working 35directory set to ``${``\ :term:`B`\ ``}``. 36 37The default behavior of this task is to run the ``oe_runmake`` function 38if a makefile (``Makefile``, ``makefile``, or ``GNUmakefile``) is found. 39If no such file is found, the :ref:`ref-tasks-compile` task does nothing. 40 41.. _ref-tasks-compile_ptest_base: 42 43``do_compile_ptest_base`` 44------------------------- 45 46Compiles the runtime test suite included in the software being built. 47 48.. _ref-tasks-configure: 49 50``do_configure`` 51---------------- 52 53Configures the source by enabling and disabling any build-time and 54configuration options for the software being built. The task runs with 55the current working directory set to ``${``\ :term:`B`\ ``}``. 56 57The default behavior of this task is to run ``oe_runmake clean`` if a 58makefile (``Makefile``, ``makefile``, or ``GNUmakefile``) is found and 59:term:`CLEANBROKEN` is not set to "1". If no such 60file is found or the :term:`CLEANBROKEN` variable is set to "1", the 61:ref:`ref-tasks-configure` task does nothing. 62 63.. _ref-tasks-configure_ptest_base: 64 65``do_configure_ptest_base`` 66--------------------------- 67 68Configures the runtime test suite included in the software being built. 69 70.. _ref-tasks-deploy: 71 72``do_deploy`` 73------------- 74 75Writes output files that are to be deployed to 76``${``\ :term:`DEPLOY_DIR_IMAGE`\ ``}``. The 77task runs with the current working directory set to 78``${``\ :term:`B`\ ``}``. 79 80Recipes implementing this task should inherit the 81:ref:`ref-classes-deploy` class and should write the output 82to ``${``\ :term:`DEPLOYDIR`\ ``}``, which is not to be 83confused with ``${DEPLOY_DIR}``. The :ref:`ref-classes-deploy` class sets up 84:ref:`ref-tasks-deploy` as a shared state (sstate) task that can be accelerated 85through sstate use. The sstate mechanism takes care of copying the 86output from ``${DEPLOYDIR}`` to ``${DEPLOY_DIR_IMAGE}``. 87 88.. note:: 89 90 Do not write the output directly to ``${DEPLOY_DIR_IMAGE}``, as this causes 91 the sstate mechanism to malfunction. 92 93The :ref:`ref-tasks-deploy` task is not added as a task by default and 94consequently needs to be added manually. If you want the task to run 95after :ref:`ref-tasks-compile`, you can add it by doing 96the following:: 97 98 addtask deploy after do_compile 99 100Adding :ref:`ref-tasks-deploy` after other tasks works the same way. 101 102.. note:: 103 104 You do not need to add ``before do_build`` to the ``addtask`` command 105 (though it is harmless), because the :ref:`ref-classes-base` class contains the following:: 106 107 do_build[recrdeptask] += "do_deploy" 108 109 110 See the ":ref:`bitbake-user-manual/bitbake-user-manual-execution:dependencies`" 111 section in the BitBake User Manual for more information. 112 113If the :ref:`ref-tasks-deploy` task re-executes, any previous output is removed 114(i.e. "cleaned"). 115 116.. _ref-tasks-fetch: 117 118``do_fetch`` 119------------ 120 121Fetches the source code. This task uses the :term:`SRC_URI` variable and the 122argument's prefix to determine the correct 123:ref:`fetcher <bitbake-user-manual/bitbake-user-manual-fetching:fetchers>` 124module. 125 126.. _ref-tasks-image: 127 128``do_image`` 129------------ 130 131Starts the image generation process. The :ref:`ref-tasks-image` task runs after 132the OpenEmbedded build system has run the 133:ref:`ref-tasks-rootfs` task during which packages are 134identified for installation into the image and the root filesystem is 135created, complete with post-processing. 136 137The :ref:`ref-tasks-image` task performs pre-processing on the image through the 138:term:`IMAGE_PREPROCESS_COMMAND` and 139dynamically generates supporting :ref:`do_image_* <ref-tasks-image>` tasks as needed. 140 141For more information on image creation, see the ":ref:`overview-manual/concepts:image generation`" 142section in the Yocto Project Overview and Concepts Manual. 143 144.. _ref-tasks-image-complete: 145 146``do_image_complete`` 147--------------------- 148 149Completes the image generation process. The :ref:`do_image_complete <ref-tasks-image-complete>` task 150runs after the OpenEmbedded build system has run the 151:ref:`ref-tasks-image` task during which image 152pre-processing occurs and through dynamically generated :ref:`do_image_* <ref-tasks-image>` 153tasks the image is constructed. 154 155The :ref:`do_image_complete <ref-tasks-image-complete>` task performs post-processing on the image 156through the 157:term:`IMAGE_POSTPROCESS_COMMAND`. 158 159For more information on image creation, see the 160":ref:`overview-manual/concepts:image generation`" 161section in the Yocto Project Overview and Concepts Manual. 162 163.. _ref-tasks-install: 164 165``do_install`` 166-------------- 167 168Copies files that are to be packaged into the holding area 169``${``\ :term:`D`\ ``}``. This task runs with the current 170working directory set to ``${``\ :term:`B`\ ``}``, which is the 171compilation directory. The :ref:`ref-tasks-install` task, as well as other tasks 172that either directly or indirectly depend on the installed files (e.g. 173:ref:`ref-tasks-package`, :ref:`do_package_write_* <ref-tasks-package_write_deb>`, and 174:ref:`ref-tasks-rootfs`), run under 175:ref:`fakeroot <overview-manual/concepts:fakeroot and pseudo>`. 176 177.. note:: 178 179 When installing files, be careful not to set the owner and group IDs 180 of the installed files to unintended values. Some methods of copying 181 files, notably when using the recursive ``cp`` command, can preserve 182 the UID and/or GID of the original file, which is usually not what 183 you want. The ``host-user-contaminated`` QA check checks for files 184 that probably have the wrong ownership. 185 186 Safe methods for installing files include the following: 187 188 - The ``install`` utility. This utility is the preferred method. 189 190 - The ``cp`` command with the ``--no-preserve=ownership`` option. 191 192 - The ``tar`` command with the ``--no-same-owner`` option. See the 193 ``bin_package.bbclass`` file in the ``meta/classes-recipe`` 194 subdirectory of the :term:`Source Directory` for an example. 195 196.. _ref-tasks-install_ptest_base: 197 198``do_install_ptest_base`` 199------------------------- 200 201Copies the runtime test suite files from the compilation directory to a 202holding area. 203 204.. _ref-tasks-package: 205 206``do_package`` 207-------------- 208 209Analyzes the content of the holding area 210``${``\ :term:`D`\ ``}`` and splits the content into subsets 211based on available packages and files. This task makes use of the 212:term:`PACKAGES` and :term:`FILES` 213variables. 214 215The :ref:`ref-tasks-package` task, in conjunction with the 216:ref:`ref-tasks-packagedata` task, also saves some 217important package metadata. For additional information, see the 218:term:`PKGDESTWORK` variable and the 219":ref:`overview-manual/concepts:automatically added runtime dependencies`" 220section in the Yocto Project Overview and Concepts Manual. 221 222.. _ref-tasks-package_qa: 223 224``do_package_qa`` 225----------------- 226 227Runs QA checks on packaged files. For more information on these checks, 228see the :ref:`ref-classes-insane` class. 229 230.. _ref-tasks-package_write_deb: 231 232``do_package_write_deb`` 233------------------------ 234 235Creates Debian packages (i.e. ``*.deb`` files) and places them in the 236``${``\ :term:`DEPLOY_DIR_DEB`\ ``}`` directory in 237the package feeds area. For more information, see the 238":ref:`overview-manual/concepts:package feeds`" section in 239the Yocto Project Overview and Concepts Manual. 240 241.. _ref-tasks-package_write_ipk: 242 243``do_package_write_ipk`` 244------------------------ 245 246Creates IPK packages (i.e. ``*.ipk`` files) and places them in the 247``${``\ :term:`DEPLOY_DIR_IPK`\ ``}`` directory in 248the package feeds area. For more information, see the 249":ref:`overview-manual/concepts:package feeds`" section in 250the Yocto Project Overview and Concepts Manual. 251 252.. _ref-tasks-package_write_rpm: 253 254``do_package_write_rpm`` 255------------------------ 256 257Creates RPM packages (i.e. ``*.rpm`` files) and places them in the 258``${``\ :term:`DEPLOY_DIR_RPM`\ ``}`` directory in 259the package feeds area. For more information, see the 260":ref:`overview-manual/concepts:package feeds`" section in 261the Yocto Project Overview and Concepts Manual. 262 263.. _ref-tasks-packagedata: 264 265``do_packagedata`` 266------------------ 267 268Saves package metadata generated by the 269:ref:`ref-tasks-package` task in 270:term:`PKGDATA_DIR` to make it available globally. 271 272.. _ref-tasks-patch: 273 274``do_patch`` 275------------ 276 277Locates patch files and applies them to the source code. 278 279After fetching and unpacking source files, the build system uses the 280recipe's :term:`SRC_URI` statements 281to locate and apply patch files to the source code. 282 283.. note:: 284 285 The build system uses the :term:`FILESPATH` variable to determine the 286 default set of directories when searching for patches. 287 288Patch files, by default, are ``*.patch`` and ``*.diff`` files created 289and kept in a subdirectory of the directory holding the recipe file. For 290example, consider the 291:yocto_git:`bluez5 </poky/tree/meta/recipes-connectivity/bluez5>` 292recipe from the OE-Core layer (i.e. ``poky/meta``):: 293 294 poky/meta/recipes-connectivity/bluez5 295 296This recipe has two patch files located here:: 297 298 poky/meta/recipes-connectivity/bluez5/bluez5 299 300In the ``bluez5`` recipe, the :term:`SRC_URI` statements point to the source 301and patch files needed to build the package. 302 303.. note:: 304 305 In the case for the ``bluez5_5.48.bb`` recipe, the :term:`SRC_URI` statements 306 are from an include file ``bluez5.inc``. 307 308As mentioned earlier, the build system treats files whose file types are 309``.patch`` and ``.diff`` as patch files. However, you can use the 310"apply=yes" parameter with the :term:`SRC_URI` statement to indicate any 311file as a patch file:: 312 313 SRC_URI = " \ 314 git://path_to_repo/some_package \ 315 file://file;apply=yes \ 316 " 317 318Conversely, if you have a file whose file type is ``.patch`` or ``.diff`` 319and you want to exclude it so that the :ref:`ref-tasks-patch` task does not apply 320it during the patch phase, you can use the "apply=no" parameter with the 321:term:`SRC_URI` statement:: 322 323 SRC_URI = " \ 324 git://path_to_repo/some_package \ 325 file://file1.patch \ 326 file://file2.patch;apply=no \ 327 " 328 329In the previous example ``file1.patch`` would be applied as a patch by default 330while ``file2.patch`` would not be applied. 331 332You can find out more about the patching process in the 333":ref:`overview-manual/concepts:patching`" section in 334the Yocto Project Overview and Concepts Manual and the 335":ref:`dev-manual/new-recipe:patching code`" section in the 336Yocto Project Development Tasks Manual. 337 338.. _ref-tasks-populate_lic: 339 340``do_populate_lic`` 341------------------- 342 343Writes license information for the recipe that is collected later when 344the image is constructed. 345 346.. _ref-tasks-populate_sdk: 347 348``do_populate_sdk`` 349------------------- 350 351Creates the file and directory structure for an installable SDK. See the 352":ref:`overview-manual/concepts:sdk generation`" 353section in the Yocto Project Overview and Concepts Manual for more 354information. 355 356.. _ref-tasks-populate_sdk_ext: 357 358``do_populate_sdk_ext`` 359----------------------- 360 361Creates the file and directory structure for an installable extensible 362SDK (eSDK). See the ":ref:`overview-manual/concepts:sdk generation`" 363section in the Yocto Project Overview and Concepts Manual for more 364information. 365 366 367.. _ref-tasks-populate_sysroot: 368 369``do_populate_sysroot`` 370----------------------- 371 372Stages (copies) a subset of the files installed by the 373:ref:`ref-tasks-install` task into the appropriate 374sysroot. For information on how to access these files from other 375recipes, see the :term:`STAGING_DIR* <STAGING_DIR_HOST>` variables. 376Directories that would typically not be needed by other recipes at build 377time (e.g. ``/etc``) are not copied by default. 378 379For information on what directories are copied by default, see the 380:term:`SYSROOT_DIRS* <SYSROOT_DIRS>` variables. You can change 381these variables inside your recipe if you need to make additional (or 382fewer) directories available to other recipes at build time. 383 384The :ref:`ref-tasks-populate_sysroot` task is a shared state (sstate) task, which 385means that the task can be accelerated through sstate use. Realize also 386that if the task is re-executed, any previous output is removed (i.e. 387"cleaned"). 388 389.. _ref-tasks-prepare_recipe_sysroot: 390 391``do_prepare_recipe_sysroot`` 392----------------------------- 393 394Installs the files into the individual recipe specific sysroots (i.e. 395``recipe-sysroot`` and ``recipe-sysroot-native`` under 396``${``\ :term:`WORKDIR`\ ``}`` based upon the 397dependencies specified by :term:`DEPENDS`). See the 398":ref:`ref-classes-staging`" class for more information. 399 400.. _ref-tasks-rm_work: 401 402``do_rm_work`` 403-------------- 404 405Removes work files after the OpenEmbedded build system has finished with 406them. You can learn more by looking at the 407":ref:`ref-classes-rm-work`" section. 408 409.. _ref-tasks-unpack: 410 411``do_unpack`` 412------------- 413 414Unpacks the source code into a working directory pointed to by 415``${``\ :term:`UNPACKDIR`\ ``}``. A legacy way to specify 416this directory is through the :term:`S` and :term:`WORKDIR` variables. 417For more information on how source files are unpacked, see the 418":ref:`overview-manual/concepts:source fetching`" 419section in the Yocto Project Overview and Concepts Manual. 420 421Manually Called Tasks 422===================== 423 424These tasks are typically manually triggered (e.g. by using the 425``bitbake -c`` command-line option): 426 427``do_checkuri`` 428--------------- 429 430Validates the :term:`SRC_URI` value. 431 432.. _ref-tasks-clean: 433 434``do_clean`` 435------------ 436 437Removes all output files for a target from the 438:ref:`ref-tasks-unpack` task forward (i.e. :ref:`ref-tasks-unpack`, 439:ref:`ref-tasks-configure`, 440:ref:`ref-tasks-compile`, 441:ref:`ref-tasks-install`, and 442:ref:`ref-tasks-package`). 443 444You can run this task using BitBake as follows:: 445 446 $ bitbake -c clean recipe 447 448Running this task does not remove the 449:ref:`sstate <overview-manual/concepts:shared state cache>` cache files. 450Consequently, if no changes have been made and the recipe is rebuilt 451after cleaning, output files are simply restored from the sstate cache. 452If you want to remove the sstate cache files for the recipe, you need to 453use the :ref:`ref-tasks-cleansstate` task instead 454(i.e. ``bitbake -c cleansstate`` recipe). 455 456.. _ref-tasks-cleanall: 457 458``do_cleanall`` 459--------------- 460 461Removes all output files, shared state 462(:ref:`sstate <overview-manual/concepts:shared state cache>`) cache, and 463downloaded source files for a target (i.e. the contents of 464:term:`DL_DIR`). Essentially, the :ref:`ref-tasks-cleanall` task is 465identical to the :ref:`ref-tasks-cleansstate` task 466with the added removal of downloaded source files. 467 468You can run this task using BitBake as follows:: 469 470 $ bitbake -c cleanall recipe 471 472You should never use the :ref:`ref-tasks-cleanall` task in a normal 473scenario. If you want to start fresh with the :ref:`ref-tasks-fetch` task, 474use instead:: 475 476 $ bitbake -f -c fetch recipe 477 478.. note:: 479 480 The reason to prefer ``bitbake -f -c fetch`` is that the 481 :ref:`ref-tasks-cleanall` task would break in some cases, such as:: 482 483 $ bitbake -c fetch recipe 484 $ bitbake -c cleanall recipe-native 485 $ bitbake -c unpack recipe 486 487 because after step 1 there is a stamp file for the 488 :ref:`ref-tasks-fetch` task of ``recipe``, and it won't be removed at 489 step 2 because step 2 uses a different work directory. So the unpack task 490 at step 3 will try to extract the downloaded archive and fail as it has 491 been deleted in step 2. 492 493 Note that this also applies to BitBake from concurrent processes when a 494 shared download directory (:term:`DL_DIR`) is setup. 495 496.. _ref-tasks-cleansstate: 497 498``do_cleansstate`` 499------------------ 500 501Removes all output files and shared state 502(:ref:`sstate <overview-manual/concepts:shared state cache>`) cache for a 503target. Essentially, the :ref:`ref-tasks-cleansstate` task is identical to the 504:ref:`ref-tasks-clean` task with the added removal of 505shared state (:ref:`sstate <overview-manual/concepts:shared state cache>`) 506cache. 507 508You can run this task using BitBake as follows:: 509 510 $ bitbake -c cleansstate recipe 511 512When you run the :ref:`ref-tasks-cleansstate` task, the OpenEmbedded build system 513no longer uses any sstate. Consequently, building the recipe from 514scratch is guaranteed. 515 516.. note:: 517 518 Using :ref:`ref-tasks-cleansstate` with a shared :term:`SSTATE_DIR` is 519 not recommended because it could trigger an error during the build of a 520 separate BitBake instance. This is because the builds check sstate "up 521 front" but download the files later, so it if is deleted in the 522 meantime, it will cause an error but not a total failure as it will 523 rebuild it. 524 525 The reliable and preferred way to force a new build is to use ``bitbake 526 -f`` instead. 527 528.. note:: 529 530 The :ref:`ref-tasks-cleansstate` task cannot remove sstate from a remote sstate 531 mirror. If you need to build a target from scratch using remote mirrors, use 532 the "-f" option as follows:: 533 534 $ bitbake -f -c do_cleansstate target 535 536 537.. _ref-tasks-pydevshell: 538 539``do_pydevshell`` 540----------------- 541 542Starts a shell in which an interactive Python interpreter allows you to 543interact with the BitBake build environment. From within this shell, you 544can directly examine and set bits from the data store and execute 545functions as if within the BitBake environment. See the ":ref:`dev-manual/python-development-shell:using a Python development shell`" section in 546the Yocto Project Development Tasks Manual for more information about 547using ``pydevshell``. 548 549.. _ref-tasks-devshell: 550 551``do_devshell`` 552--------------- 553 554Starts a shell whose environment is set up for development, debugging, 555or both. See the ":ref:`dev-manual/development-shell:using a development shell`" section in the 556Yocto Project Development Tasks Manual for more information about using 557``devshell``. 558 559.. _ref-tasks-listtasks: 560 561``do_listtasks`` 562---------------- 563 564Lists all defined tasks for a target. 565 566.. _ref-tasks-package_index: 567 568``do_package_index`` 569-------------------- 570 571Creates or updates the index in the :ref:`overview-manual/concepts:package feeds` area. 572 573.. note:: 574 575 This task is not triggered with the ``bitbake -c`` command-line option as 576 are the other tasks in this section. Because this task is specifically for 577 the ``package-index`` recipe, you run it using ``bitbake package-index``. 578 579Image-Related Tasks 580=================== 581 582The following tasks are applicable to image recipes. 583 584.. _ref-tasks-bootimg: 585 586``do_bootimg`` 587-------------- 588 589Creates a bootable live image. See the 590:term:`IMAGE_FSTYPES` variable for additional 591information on live image types. 592 593.. _ref-tasks-bundle_initramfs: 594 595``do_bundle_initramfs`` 596----------------------- 597 598Combines an :term:`Initramfs` image and kernel together to 599form a single image. 600 601.. _ref-tasks-rootfs: 602 603``do_rootfs`` 604------------- 605 606Creates the root filesystem (file and directory structure) for an image. 607See the ":ref:`overview-manual/concepts:image generation`" 608section in the Yocto Project Overview and Concepts Manual for more 609information on how the root filesystem is created. 610 611.. _ref-tasks-testimage: 612 613``do_testimage`` 614---------------- 615 616Boots an image and performs runtime tests within the image. For 617information on automatically testing images, see the 618":ref:`test-manual/runtime-testing:performing automated runtime testing`" 619section in the Yocto Project Test Environment Manual. 620 621.. _ref-tasks-testimage_auto: 622 623``do_testimage_auto`` 624--------------------- 625 626Boots an image and performs runtime tests within the image immediately 627after it has been built. This task is enabled when you set 628:term:`TESTIMAGE_AUTO` equal to "1". 629 630For information on automatically testing images, see the 631":ref:`test-manual/runtime-testing:performing automated runtime testing`" 632section in the Yocto Project Test Environment Manual. 633 634Kernel-Related Tasks 635==================== 636 637The following tasks are applicable to kernel recipes. Some of these 638tasks (e.g. the :ref:`ref-tasks-menuconfig` task) are 639also applicable to recipes that use Linux kernel style configuration 640such as the BusyBox recipe. 641 642.. _ref-tasks-compile_kernelmodules: 643 644``do_compile_kernelmodules`` 645---------------------------- 646 647Runs the step that builds the kernel modules (if needed). Building a 648kernel consists of two steps: 1) the kernel (``vmlinux``) is built, and 6492) the modules are built (i.e. ``make modules``). 650 651.. _ref-tasks-diffconfig: 652 653``do_diffconfig`` 654----------------- 655 656When invoked by the user, this task creates a file containing the 657differences between the original config as produced by 658:ref:`ref-tasks-kernel_configme` task and the 659changes made by the user with other methods (i.e. using 660(:ref:`ref-tasks-kernel_menuconfig`). Once the 661file of differences is created, it can be used to create a config 662fragment that only contains the differences. You can invoke this task 663from the command line as follows:: 664 665 $ bitbake linux-yocto -c diffconfig 666 667For more information, see the 668":ref:`kernel-dev/common:creating configuration fragments`" 669section in the Yocto Project Linux Kernel Development Manual. 670 671.. _ref-tasks-kernel_checkout: 672 673``do_kernel_checkout`` 674---------------------- 675 676Converts the newly unpacked kernel source into a form with which the 677OpenEmbedded build system can work. Because the kernel source can be 678fetched in several different ways, the :ref:`ref-tasks-kernel_checkout` task makes 679sure that subsequent tasks are given a clean working tree copy of the 680kernel with the correct branches checked out. 681 682.. _ref-tasks-kernel_configcheck: 683 684``do_kernel_configcheck`` 685------------------------- 686 687Validates the configuration produced by the 688:ref:`ref-tasks-kernel_menuconfig` task. The 689:ref:`ref-tasks-kernel_configcheck` task produces warnings when a requested 690configuration does not appear in the final ``.config`` file or when you 691override a policy configuration in a hardware configuration fragment. 692You can run this task explicitly and view the output by using the 693following command:: 694 695 $ bitbake linux-yocto -c kernel_configcheck -f 696 697For more information, see the 698":ref:`kernel-dev/common:validating configuration`" 699section in the Yocto Project Linux Kernel Development Manual. 700 701.. _ref-tasks-kernel_configme: 702 703``do_kernel_configme`` 704---------------------- 705 706After the kernel is patched by the :ref:`ref-tasks-patch` 707task, the :ref:`ref-tasks-kernel_configme` task assembles and merges all the 708kernel config fragments into a merged configuration that can then be 709passed to the kernel configuration phase proper. This is also the time 710during which user-specified defconfigs are applied if present, and where 711configuration modes such as ``--allnoconfig`` are applied. 712 713.. _ref-tasks-kernel_menuconfig: 714 715``do_kernel_menuconfig`` 716------------------------ 717 718Invoked by the user to manipulate the ``.config`` file used to build a 719linux-yocto recipe. This task starts the Linux kernel configuration 720tool, which you then use to modify the kernel configuration. 721 722.. note:: 723 724 You can also invoke this tool from the command line as follows:: 725 726 $ bitbake linux-yocto -c menuconfig 727 728 729See the ":ref:`kernel-dev/common:using \`\`menuconfig\`\``" 730section in the Yocto Project Linux Kernel Development Manual for more 731information on this configuration tool. 732 733.. _ref-tasks-kernel_metadata: 734 735``do_kernel_metadata`` 736---------------------- 737 738Collects all the features required for a given kernel build, whether the 739features come from :term:`SRC_URI` or from Git 740repositories. After collection, the :ref:`ref-tasks-kernel_metadata` task 741processes the features into a series of config fragments and patches, 742which can then be applied by subsequent tasks such as 743:ref:`ref-tasks-patch` and 744:ref:`ref-tasks-kernel_configme`. 745 746.. _ref-tasks-menuconfig: 747 748``do_menuconfig`` 749----------------- 750 751Runs ``make menuconfig`` for the kernel. For information on 752``menuconfig``, see the 753":ref:`kernel-dev/common:using \`\`menuconfig\`\``" 754section in the Yocto Project Linux Kernel Development Manual. 755 756.. _ref-tasks-savedefconfig: 757 758``do_savedefconfig`` 759-------------------- 760 761When invoked by the user, creates a defconfig file that can be used 762instead of the default defconfig. The saved defconfig contains the 763differences between the default defconfig and the changes made by the 764user using other methods (i.e. the 765:ref:`ref-tasks-kernel_menuconfig` task. You 766can invoke the task using the following command:: 767 768 $ bitbake linux-yocto -c savedefconfig 769 770.. _ref-tasks-shared_workdir: 771 772``do_shared_workdir`` 773--------------------- 774 775After the kernel has been compiled but before the kernel modules have 776been compiled, this task copies files required for module builds and 777which are generated from the kernel build into the shared work 778directory. With these copies successfully copied, the 779:ref:`ref-tasks-compile_kernelmodules` task 780can successfully build the kernel modules in the next step of the build. 781 782.. _ref-tasks-sizecheck: 783 784``do_sizecheck`` 785---------------- 786 787After the kernel has been built, this task checks the size of the 788stripped kernel image against 789:term:`KERNEL_IMAGE_MAXSIZE`. If that 790variable was set and the size of the stripped kernel exceeds that size, 791the kernel build produces a warning to that effect. 792 793.. _ref-tasks-strip: 794 795``do_strip`` 796------------ 797 798If ``KERNEL_IMAGE_STRIP_EXTRA_SECTIONS`` is defined, this task strips 799the sections named in that variable from ``vmlinux``. This stripping is 800typically used to remove nonessential sections such as ``.comment`` 801sections from a size-sensitive configuration. 802 803.. _ref-tasks-validate_branches: 804 805``do_validate_branches`` 806------------------------ 807 808After the kernel is unpacked but before it is patched, this task makes 809sure that the machine and metadata branches as specified by the 810:term:`SRCREV` variables actually exist on the specified 811branches. Otherwise, if :term:`AUTOREV` is not being used, the 812:ref:`ref-tasks-validate_branches` task fails during the build. 813