development-shell.rst 3.2 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182
  1. .. SPDX-License-Identifier: CC-BY-SA-2.0-UK
  2. Using a Development Shell
  3. *************************
  4. When debugging certain commands or even when just editing packages,
  5. ``devshell`` can be a useful tool. When you invoke ``devshell``, all
  6. tasks up to and including
  7. :ref:`ref-tasks-patch` are run for the
  8. specified target. Then, a new terminal is opened and you are placed in
  9. ``${``\ :term:`S`\ ``}``, the source
  10. directory. In the new terminal, all the OpenEmbedded build-related
  11. environment variables are still defined so you can use commands such as
  12. ``configure`` and ``make``. The commands execute just as if the
  13. OpenEmbedded build system were executing them. Consequently, working
  14. this way can be helpful when debugging a build or preparing software to
  15. be used with the OpenEmbedded build system.
  16. Following is an example that uses ``devshell`` on a target named
  17. ``matchbox-desktop``::
  18. $ bitbake matchbox-desktop -c devshell
  19. This command spawns a terminal with a shell prompt within the
  20. OpenEmbedded build environment. The
  21. :term:`OE_TERMINAL` variable
  22. controls what type of shell is opened.
  23. For spawned terminals, the following occurs:
  24. - The ``PATH`` variable includes the cross-toolchain.
  25. - The ``pkgconfig`` variables find the correct ``.pc`` files.
  26. - The ``configure`` command finds the Yocto Project site files as well
  27. as any other necessary files.
  28. Within this environment, you can run configure or compile commands as if
  29. they were being run by the OpenEmbedded build system itself. As noted
  30. earlier, the working directory also automatically changes to the Source
  31. Directory (:term:`S`).
  32. To manually run a specific task using ``devshell``, run the
  33. corresponding ``run.*`` script in the
  34. ``${``\ :term:`WORKDIR`\ ``}/temp``
  35. directory (e.g., ``run.do_configure.``\ `pid`). If a task's script does
  36. not exist, which would be the case if the task was skipped by way of the
  37. sstate cache, you can create the task by first running it outside of the
  38. ``devshell``::
  39. $ bitbake -c task
  40. .. note::
  41. - Execution of a task's ``run.*`` script and BitBake's execution of
  42. a task are identical. In other words, running the script re-runs
  43. the task just as it would be run using the ``bitbake -c`` command.
  44. - Any ``run.*`` file that does not have a ``.pid`` extension is a
  45. symbolic link (symlink) to the most recent version of that file.
  46. Remember, that the ``devshell`` is a mechanism that allows you to get
  47. into the BitBake task execution environment. And as such, all commands
  48. must be called just as BitBake would call them. That means you need to
  49. provide the appropriate options for cross-compilation and so forth as
  50. applicable.
  51. When you are finished using ``devshell``, exit the shell or close the
  52. terminal window.
  53. .. note::
  54. - It is worth remembering that when using ``devshell`` you need to
  55. use the full compiler name such as ``arm-poky-linux-gnueabi-gcc``
  56. instead of just using ``gcc``. The same applies to other
  57. applications such as ``binutils``, ``libtool`` and so forth.
  58. BitBake sets up environment variables such as :term:`CC` to assist
  59. applications, such as ``make`` to find the correct tools.
  60. - It is also worth noting that ``devshell`` still works over X11
  61. forwarding and similar situations.