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:bitbake-user-manual/bitbake-user-manual-metadata:tasks`" and 18":ref:`bitbake: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 ``do_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``do_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:`deploy <ref-classes-deploy>` class and should write the output 82to ``${``\ :term:`DEPLOYDIR`\ ``}``, which is not to be 83confused with ``${DEPLOY_DIR}``. The :ref:`deploy <ref-classes-deploy>` class sets up 84``do_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 ``do_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 ``do_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:`base <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 ``do_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 122:term:`SRC_URI` variable and the argument's prefix to 123determine the correct :ref:`fetcher <bitbake: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 ``do_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 ``do_image`` task performs pre-processing on the image through the 138:term:`IMAGE_PREPROCESS_COMMAND` and 139dynamically generates supporting ``do_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 ``do_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 ``do_image_*`` 153tasks the image is constructed. 154 155The ``do_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 ``do_install`` task, as well as other tasks 172that either directly or indirectly depend on the installed files (e.g. 173:ref:`ref-tasks-package`, ``do_package_write_*``, 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`` directory of 194 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 ``do_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:`insane <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-package_write_tar: 264 265``do_package_write_tar`` 266------------------------ 267 268Creates tarballs and places them in the 269``${``\ :term:`DEPLOY_DIR_TAR`\ ``}`` directory in 270the package feeds area. For more information, see the 271":ref:`overview-manual/concepts:package feeds`" section in 272the Yocto Project Overview and Concepts Manual. 273 274.. _ref-tasks-packagedata: 275 276``do_packagedata`` 277------------------ 278 279Saves package metadata generated by the 280:ref:`ref-tasks-package` task in 281:term:`PKGDATA_DIR` to make it available globally. 282 283.. _ref-tasks-patch: 284 285``do_patch`` 286------------ 287 288Locates patch files and applies them to the source code. 289 290After fetching and unpacking source files, the build system uses the 291recipe's :term:`SRC_URI` statements 292to locate and apply patch files to the source code. 293 294.. note:: 295 296 The build system uses the :term:`FILESPATH` variable to determine the 297 default set of directories when searching for patches. 298 299Patch files, by default, are ``*.patch`` and ``*.diff`` files created 300and kept in a subdirectory of the directory holding the recipe file. For 301example, consider the 302:yocto_git:`bluez5 </poky/tree/meta/recipes-connectivity/bluez5>` 303recipe from the OE-Core layer (i.e. ``poky/meta``):: 304 305 poky/meta/recipes-connectivity/bluez5 306 307This recipe has two patch files located here:: 308 309 poky/meta/recipes-connectivity/bluez5/bluez5 310 311In the ``bluez5`` recipe, the :term:`SRC_URI` statements point to the source 312and patch files needed to build the package. 313 314.. note:: 315 316 In the case for the ``bluez5_5.48.bb`` recipe, the :term:`SRC_URI` statements 317 are from an include file ``bluez5.inc``. 318 319As mentioned earlier, the build system treats files whose file types are 320``.patch`` and ``.diff`` as patch files. However, you can use the 321"apply=yes" parameter with the :term:`SRC_URI` statement to indicate any 322file as a patch file:: 323 324 SRC_URI = " \ 325 git://path_to_repo/some_package \ 326 file://file;apply=yes \ 327 " 328 329Conversely, if you have a file whose file type is ``.patch`` or ``.diff`` 330and you want to exclude it so that the ``do_patch`` task does not apply 331it during the patch phase, you can use the "apply=no" parameter with the 332:term:`SRC_URI` statement:: 333 334 SRC_URI = " \ 335 git://path_to_repo/some_package \ 336 file://file1.patch \ 337 file://file2.patch;apply=no \ 338 " 339 340In the previous example ``file1.patch`` would be applied as a patch by default 341while ``file2.patch`` would not be applied. 342 343You can find out more about the patching process in the 344":ref:`overview-manual/concepts:patching`" section in 345the Yocto Project Overview and Concepts Manual and the 346":ref:`dev-manual/common-tasks:patching code`" section in the 347Yocto Project Development Tasks Manual. 348 349.. _ref-tasks-populate_lic: 350 351``do_populate_lic`` 352------------------- 353 354Writes license information for the recipe that is collected later when 355the image is constructed. 356 357.. _ref-tasks-populate_sdk: 358 359``do_populate_sdk`` 360------------------- 361 362Creates the file and directory structure for an installable SDK. See the 363":ref:`overview-manual/concepts:sdk generation`" 364section in the Yocto Project Overview and Concepts Manual for more 365information. 366 367.. _ref-tasks-populate_sdk_ext: 368 369``do_populate_sdk_ext`` 370----------------------- 371 372Creates the file and directory structure for an installable extensible 373SDK (eSDK). See the ":ref:`overview-manual/concepts:sdk generation`" 374section in the Yocto Project Overview and Concepts Manual for more 375information. 376 377 378.. _ref-tasks-populate_sysroot: 379 380``do_populate_sysroot`` 381----------------------- 382 383Stages (copies) a subset of the files installed by the 384:ref:`ref-tasks-install` task into the appropriate 385sysroot. For information on how to access these files from other 386recipes, see the :term:`STAGING_DIR* <STAGING_DIR_HOST>` variables. 387Directories that would typically not be needed by other recipes at build 388time (e.g. ``/etc``) are not copied by default. 389 390For information on what directories are copied by default, see the 391:term:`SYSROOT_DIRS* <SYSROOT_DIRS>` variables. You can change 392these variables inside your recipe if you need to make additional (or 393fewer) directories available to other recipes at build time. 394 395The ``do_populate_sysroot`` task is a shared state (sstate) task, which 396means that the task can be accelerated through sstate use. Realize also 397that if the task is re-executed, any previous output is removed (i.e. 398"cleaned"). 399 400.. _ref-tasks-prepare_recipe_sysroot: 401 402``do_prepare_recipe_sysroot`` 403----------------------------- 404 405Installs the files into the individual recipe specific sysroots (i.e. 406``recipe-sysroot`` and ``recipe-sysroot-native`` under 407``${``\ :term:`WORKDIR`\ ``}`` based upon the 408dependencies specified by :term:`DEPENDS`). See the 409":ref:`staging <ref-classes-staging>`" class for more information. 410 411.. _ref-tasks-rm_work: 412 413``do_rm_work`` 414-------------- 415 416Removes work files after the OpenEmbedded build system has finished with 417them. You can learn more by looking at the 418":ref:`ref-classes-rm-work`" section. 419 420.. _ref-tasks-unpack: 421 422``do_unpack`` 423------------- 424 425Unpacks the source code into a working directory pointed to by 426``${``\ :term:`WORKDIR`\ ``}``. The :term:`S` 427variable also plays a role in where unpacked source files ultimately 428reside. For more information on how source files are unpacked, see the 429":ref:`overview-manual/concepts:source fetching`" 430section in the Yocto Project Overview and Concepts Manual and also see 431the :term:`WORKDIR` and :term:`S` variable descriptions. 432 433Manually Called Tasks 434===================== 435 436These tasks are typically manually triggered (e.g. by using the 437``bitbake -c`` command-line option): 438 439``do_checkuri`` 440--------------- 441 442Validates the :term:`SRC_URI` value. 443 444.. _ref-tasks-clean: 445 446``do_clean`` 447------------ 448 449Removes all output files for a target from the 450:ref:`ref-tasks-unpack` task forward (i.e. ``do_unpack``, 451:ref:`ref-tasks-configure`, 452:ref:`ref-tasks-compile`, 453:ref:`ref-tasks-install`, and 454:ref:`ref-tasks-package`). 455 456You can run this task using BitBake as follows:: 457 458 $ bitbake -c clean recipe 459 460Running this task does not remove the 461:ref:`sstate <overview-manual/concepts:shared state cache>` cache files. 462Consequently, if no changes have been made and the recipe is rebuilt 463after cleaning, output files are simply restored from the sstate cache. 464If you want to remove the sstate cache files for the recipe, you need to 465use the :ref:`ref-tasks-cleansstate` task instead 466(i.e. ``bitbake -c cleansstate`` recipe). 467 468.. _ref-tasks-cleanall: 469 470``do_cleanall`` 471--------------- 472 473Removes all output files, shared state 474(:ref:`sstate <overview-manual/concepts:shared state cache>`) cache, and 475downloaded source files for a target (i.e. the contents of 476:term:`DL_DIR`). Essentially, the ``do_cleanall`` task is 477identical to the :ref:`ref-tasks-cleansstate` task 478with the added removal of downloaded source files. 479 480You can run this task using BitBake as follows:: 481 482 $ bitbake -c cleanall recipe 483 484Typically, you would not normally use the ``cleanall`` task. Do so only 485if you want to start fresh with the :ref:`ref-tasks-fetch` 486task. 487 488.. _ref-tasks-cleansstate: 489 490``do_cleansstate`` 491------------------ 492 493Removes all output files and shared state 494(:ref:`sstate <overview-manual/concepts:shared state cache>`) cache for a 495target. Essentially, the ``do_cleansstate`` task is identical to the 496:ref:`ref-tasks-clean` task with the added removal of 497shared state (:ref:`sstate <overview-manual/concepts:shared state cache>`) 498cache. 499 500You can run this task using BitBake as follows:: 501 502 $ bitbake -c cleansstate recipe 503 504When you run the ``do_cleansstate`` task, the OpenEmbedded build system 505no longer uses any sstate. Consequently, building the recipe from 506scratch is guaranteed. 507 508.. note:: 509 510 The ``do_cleansstate`` task cannot remove sstate from a remote sstate 511 mirror. If you need to build a target from scratch using remote mirrors, use 512 the "-f" option as follows:: 513 514 $ bitbake -f -c do_cleansstate target 515 516 517.. _ref-tasks-pydevshell: 518 519``do_pydevshell`` 520----------------- 521 522Starts a shell in which an interactive Python interpreter allows you to 523interact with the BitBake build environment. From within this shell, you 524can directly examine and set bits from the data store and execute 525functions as if within the BitBake environment. See the ":ref:`dev-manual/common-tasks:using a python development shell`" section in 526the Yocto Project Development Tasks Manual for more information about 527using ``pydevshell``. 528 529.. _ref-tasks-devshell: 530 531``do_devshell`` 532--------------- 533 534Starts a shell whose environment is set up for development, debugging, 535or both. See the ":ref:`dev-manual/common-tasks:using a development shell`" section in the 536Yocto Project Development Tasks Manual for more information about using 537``devshell``. 538 539.. _ref-tasks-listtasks: 540 541``do_listtasks`` 542---------------- 543 544Lists all defined tasks for a target. 545 546.. _ref-tasks-package_index: 547 548``do_package_index`` 549-------------------- 550 551Creates or updates the index in the :ref:`overview-manual/concepts:package feeds` area. 552 553.. note:: 554 555 This task is not triggered with the ``bitbake -c`` command-line option as 556 are the other tasks in this section. Because this task is specifically for 557 the ``package-index`` recipe, you run it using ``bitbake package-index``. 558 559Image-Related Tasks 560=================== 561 562The following tasks are applicable to image recipes. 563 564.. _ref-tasks-bootimg: 565 566``do_bootimg`` 567-------------- 568 569Creates a bootable live image. See the 570:term:`IMAGE_FSTYPES` variable for additional 571information on live image types. 572 573.. _ref-tasks-bundle_initramfs: 574 575``do_bundle_initramfs`` 576----------------------- 577 578Combines an initial RAM disk (initramfs) image and kernel together to 579form a single image. The 580:term:`CONFIG_INITRAMFS_SOURCE` variable 581has some more information about these types of images. 582 583.. _ref-tasks-rootfs: 584 585``do_rootfs`` 586------------- 587 588Creates the root filesystem (file and directory structure) for an image. 589See the ":ref:`overview-manual/concepts:image generation`" 590section in the Yocto Project Overview and Concepts Manual for more 591information on how the root filesystem is created. 592 593.. _ref-tasks-testimage: 594 595``do_testimage`` 596---------------- 597 598Boots an image and performs runtime tests within the image. For 599information on automatically testing images, see the 600":ref:`dev-manual/common-tasks:performing automated runtime testing`" 601section in the Yocto Project Development Tasks Manual. 602 603.. _ref-tasks-testimage_auto: 604 605``do_testimage_auto`` 606--------------------- 607 608Boots an image and performs runtime tests within the image immediately 609after it has been built. This task is enabled when you set 610:term:`TESTIMAGE_AUTO` equal to "1". 611 612For information on automatically testing images, see the 613":ref:`dev-manual/common-tasks:performing automated runtime testing`" 614section in the Yocto Project Development Tasks Manual. 615 616Kernel-Related Tasks 617==================== 618 619The following tasks are applicable to kernel recipes. Some of these 620tasks (e.g. the :ref:`ref-tasks-menuconfig` task) are 621also applicable to recipes that use Linux kernel style configuration 622such as the BusyBox recipe. 623 624.. _ref-tasks-compile_kernelmodules: 625 626``do_compile_kernelmodules`` 627---------------------------- 628 629Runs the step that builds the kernel modules (if needed). Building a 630kernel consists of two steps: 1) the kernel (``vmlinux``) is built, and 6312) the modules are built (i.e. ``make modules``). 632 633.. _ref-tasks-diffconfig: 634 635``do_diffconfig`` 636----------------- 637 638When invoked by the user, this task creates a file containing the 639differences between the original config as produced by 640:ref:`ref-tasks-kernel_configme` task and the 641changes made by the user with other methods (i.e. using 642(:ref:`ref-tasks-kernel_menuconfig`). Once the 643file of differences is created, it can be used to create a config 644fragment that only contains the differences. You can invoke this task 645from the command line as follows:: 646 647 $ bitbake linux-yocto -c diffconfig 648 649For more information, see the 650":ref:`kernel-dev/common:creating configuration fragments`" 651section in the Yocto Project Linux Kernel Development Manual. 652 653.. _ref-tasks-kernel_checkout: 654 655``do_kernel_checkout`` 656---------------------- 657 658Converts the newly unpacked kernel source into a form with which the 659OpenEmbedded build system can work. Because the kernel source can be 660fetched in several different ways, the ``do_kernel_checkout`` task makes 661sure that subsequent tasks are given a clean working tree copy of the 662kernel with the correct branches checked out. 663 664.. _ref-tasks-kernel_configcheck: 665 666``do_kernel_configcheck`` 667------------------------- 668 669Validates the configuration produced by the 670:ref:`ref-tasks-kernel_menuconfig` task. The 671``do_kernel_configcheck`` task produces warnings when a requested 672configuration does not appear in the final ``.config`` file or when you 673override a policy configuration in a hardware configuration fragment. 674You can run this task explicitly and view the output by using the 675following command:: 676 677 $ bitbake linux-yocto -c kernel_configcheck -f 678 679For more information, see the 680":ref:`kernel-dev/common:validating configuration`" 681section in the Yocto Project Linux Kernel Development Manual. 682 683.. _ref-tasks-kernel_configme: 684 685``do_kernel_configme`` 686---------------------- 687 688After the kernel is patched by the :ref:`ref-tasks-patch` 689task, the ``do_kernel_configme`` task assembles and merges all the 690kernel config fragments into a merged configuration that can then be 691passed to the kernel configuration phase proper. This is also the time 692during which user-specified defconfigs are applied if present, and where 693configuration modes such as ``--allnoconfig`` are applied. 694 695.. _ref-tasks-kernel_menuconfig: 696 697``do_kernel_menuconfig`` 698------------------------ 699 700Invoked by the user to manipulate the ``.config`` file used to build a 701linux-yocto recipe. This task starts the Linux kernel configuration 702tool, which you then use to modify the kernel configuration. 703 704.. note:: 705 706 You can also invoke this tool from the command line as follows:: 707 708 $ bitbake linux-yocto -c menuconfig 709 710 711See the ":ref:`kernel-dev/common:using \`\`menuconfig\`\``" 712section in the Yocto Project Linux Kernel Development Manual for more 713information on this configuration tool. 714 715.. _ref-tasks-kernel_metadata: 716 717``do_kernel_metadata`` 718---------------------- 719 720Collects all the features required for a given kernel build, whether the 721features come from :term:`SRC_URI` or from Git 722repositories. After collection, the ``do_kernel_metadata`` task 723processes the features into a series of config fragments and patches, 724which can then be applied by subsequent tasks such as 725:ref:`ref-tasks-patch` and 726:ref:`ref-tasks-kernel_configme`. 727 728.. _ref-tasks-menuconfig: 729 730``do_menuconfig`` 731----------------- 732 733Runs ``make menuconfig`` for the kernel. For information on 734``menuconfig``, see the 735":ref:`kernel-dev/common:using \`\`menuconfig\`\``" 736section in the Yocto Project Linux Kernel Development Manual. 737 738.. _ref-tasks-savedefconfig: 739 740``do_savedefconfig`` 741-------------------- 742 743When invoked by the user, creates a defconfig file that can be used 744instead of the default defconfig. The saved defconfig contains the 745differences between the default defconfig and the changes made by the 746user using other methods (i.e. the 747:ref:`ref-tasks-kernel_menuconfig` task. You 748can invoke the task using the following command:: 749 750 $ bitbake linux-yocto -c savedefconfig 751 752.. _ref-tasks-shared_workdir: 753 754``do_shared_workdir`` 755--------------------- 756 757After the kernel has been compiled but before the kernel modules have 758been compiled, this task copies files required for module builds and 759which are generated from the kernel build into the shared work 760directory. With these copies successfully copied, the 761:ref:`ref-tasks-compile_kernelmodules` task 762can successfully build the kernel modules in the next step of the build. 763 764.. _ref-tasks-sizecheck: 765 766``do_sizecheck`` 767---------------- 768 769After the kernel has been built, this task checks the size of the 770stripped kernel image against 771:term:`KERNEL_IMAGE_MAXSIZE`. If that 772variable was set and the size of the stripped kernel exceeds that size, 773the kernel build produces a warning to that effect. 774 775.. _ref-tasks-strip: 776 777``do_strip`` 778------------ 779 780If ``KERNEL_IMAGE_STRIP_EXTRA_SECTIONS`` is defined, this task strips 781the sections named in that variable from ``vmlinux``. This stripping is 782typically used to remove nonessential sections such as ``.comment`` 783sections from a size-sensitive configuration. 784 785.. _ref-tasks-validate_branches: 786 787``do_validate_branches`` 788------------------------ 789 790After the kernel is unpacked but before it is patched, this task makes 791sure that the machine and metadata branches as specified by the 792:term:`SRCREV` variables actually exist on the specified 793branches. Otherwise, if :term:`AUTOREV` is not being used, the 794``do_validate_branches`` task fails during the build. 795