using-buildroot-development.txt 3.4 KB

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