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