using-buildroot-development.txt 3.4 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283
  1. // -*- mode:doc; -*-
  2. // vim: set syntax=asciidoc:
  3. ==== Using Buildroot during development
  4. The normal operation of Buildroot is to download a tarball, extract
  5. it, configure, compile and install the software component found inside
  6. this tarball. The source code is extracted in
  7. +output/build/<package>-<version>+, which is a temporary directory:
  8. whenever +make clean+ is used, this directory is entirely removed, and
  9. re-created at the next +make+ invocation. Even when a Git or
  10. Subversion repository is used as the input for the package source
  11. code, Buildroot creates a tarball out of it, and then behaves as it
  12. normally does with tarballs.
  13. This behavior is well-suited when Buildroot is used mainly as an
  14. integration tool, to build and integrate all the components of an
  15. embedded Linux system. However, if one uses Buildroot during the
  16. development of certain components of the system, this behavior is not
  17. very convenient: one would instead like to make a small change to the
  18. source code of one package, and be able to quickly rebuild the system
  19. with Buildroot.
  20. Making changes directly in +output/build/<package>-<version>+ is not
  21. an appropriate solution, because this directory is removed on +make
  22. clean+.
  23. Therefore, Buildroot provides a specific mechanism for this use case:
  24. the +<pkg>_OVERRIDE_SRCDIR+ mechanism. Buildroot reads an _override_
  25. file, which allows the user to tell Buildroot the location of the
  26. source for certain packages. By default this _override_ file is named
  27. +local.mk+ and located in the top directory of the Buildroot source
  28. tree, but a different location can be specified through the
  29. +BR2_PACKAGE_OVERRIDE_FILE+ configuration option.
  30. In this _override_ file, Buildroot expects to find lines of the form:
  31. ------------------
  32. <pkg1>_OVERRIDE_SRCDIR = /path/to/pkg1/sources
  33. <pkg2>_OVERRIDE_SRCDIR = /path/to/pkg2/sources
  34. ------------------
  35. For example:
  36. ------------------
  37. LINUX_OVERRIDE_SRCDIR = /home/bob/linux/
  38. BUSYBOX_OVERRIDE_SRCDIR = /home/bob/busybox/
  39. ------------------
  40. When Buildroot finds that for a given package, an
  41. +<pkg>_OVERRIDE_SRCDIR+ has been defined, it will no longer attempt to
  42. download, extract and patch the package. Instead, it will directly use
  43. the source code available in in the specified directory and +make
  44. clean+ will not touch this directory. This allows to point Buildroot
  45. to your own directories, that can be managed by Git, Subversion, or
  46. any other version control system. To achieve this, Buildroot will use
  47. _rsync_ to copy the source code of the component from the specified
  48. +<pkg>_OVERRIDE_SRCDIR+ to +output/build/<package>-custom/+.
  49. This mechanism is best used in conjunction with the +make
  50. <pkg>-rebuild+ and +make <pkg>-reconfigure+ targets. A +make
  51. <pkg>-rebuild all+ sequence will _rsync_ the source code from
  52. +<pkg>_OVERRIDE_SRCDIR+ to +output/build/<package>-custom+ (thanks to
  53. _rsync_, only the modified files are copied), and restart the build
  54. process of just this package.
  55. In the example of the +linux+ package above, the developer can then
  56. make a source code change in +/home/bob/linux+ and then run:
  57. -----------------------
  58. make linux-rebuild all
  59. -----------------------
  60. and in a matter of seconds gets the updated Linux kernel image in
  61. +output/images+. Similarly, a change can be made to the BusyBox source
  62. code in +/home/bob/busybox+, and after:
  63. -----------------------
  64. make busybox-rebuild all
  65. -----------------------
  66. the root filesystem image in +output/images+ contains the updated
  67. BusyBox.