Advertisement
Guest User

Untitled

a guest
Dec 13th, 2017
118
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 10.26 KB | None | 0 0
  1. #
  2. # This file is your local configuration file and is where all local user settings
  3. # are placed. The comments in this file give some guide to the options a new user
  4. # to the system might want to change but pretty much any configuration option can
  5. # be set in this file. More adventurous users can look at local.conf.extended
  6. # which contains other examples of configuration which can be placed in this file
  7. # but new users likely won't need any of them initially.
  8. #
  9. # Lines starting with the '#' character are commented out and in some cases the
  10. # default values are provided as comments to show people example syntax. Enabling
  11. # the option is a question of removing the # character and making any change to the
  12. # variable as required.
  13.  
  14. #
  15. # Machine Selection
  16. #
  17. # You need to select a specific machine to target the build with. There are a selection
  18. # of emulated machines available which can boot and run in the QEMU emulator:
  19. #
  20. #MACHINE ?= "qemuarm"
  21. #MACHINE ?= "qemuarm64"
  22. #MACHINE ?= "qemumips"
  23. #MACHINE ?= "qemumips64"
  24. #MACHINE ?= "qemuppc"
  25. #MACHINE ?= "qemux86"
  26. #MACHINE ?= "qemux86-64"
  27. #
  28. # There are also the following hardware board target machines included for
  29. # demonstration purposes:
  30. #
  31. #MACHINE ?= "beaglebone-yocto"
  32. #MACHINE ?= "genericx86"
  33. #MACHINE ?= "genericx86-64"
  34. #MACHINE ?= "mpc8315e-rdb"
  35. #MACHINE ?= "edgerouter"
  36. #
  37. # This sets the default machine to be qemux86 if no other machine is selected:
  38. MACHINE ??= "qemux86"
  39.  
  40. #
  41. # Where to place downloads
  42. #
  43. # During a first build the system will download many different source code tarballs
  44. # from various upstream projects. This can take a while, particularly if your network
  45. # connection is slow. These are all stored in DL_DIR. When wiping and rebuilding you
  46. # can preserve this directory to speed up this part of subsequent builds. This directory
  47. # is safe to share between multiple builds on the same machine too.
  48. #
  49. # The default is a downloads directory under TOPDIR which is the build directory.
  50. #
  51. #DL_DIR ?= "${TOPDIR}/downloads"
  52.  
  53. #
  54. # Where to place shared-state files
  55. #
  56. # BitBake has the capability to accelerate builds based on previously built output.
  57. # This is done using "shared state" files which can be thought of as cache objects
  58. # and this option determines where those files are placed.
  59. #
  60. # You can wipe out TMPDIR leaving this directory intact and the build would regenerate
  61. # from these files if no changes were made to the configuration. If changes were made
  62. # to the configuration, only shared state files where the state was still valid would
  63. # be used (done using checksums).
  64. #
  65. # The default is a sstate-cache directory under TOPDIR.
  66. #
  67. #SSTATE_DIR ?= "${TOPDIR}/sstate-cache"
  68.  
  69. #
  70. # Where to place the build output
  71. #
  72. # This option specifies where the bulk of the building work should be done and
  73. # where BitBake should place its temporary files and output. Keep in mind that
  74. # this includes the extraction and compilation of many applications and the toolchain
  75. # which can use Gigabytes of hard disk space.
  76. #
  77. # The default is a tmp directory under TOPDIR.
  78. #
  79. #TMPDIR = "${TOPDIR}/tmp"
  80.  
  81. #
  82. # Default policy config
  83. #
  84. # The distribution setting controls which policy settings are used as defaults.
  85. # The default value is fine for general Yocto project use, at least initially.
  86. # Ultimately when creating custom policy, people will likely end up subclassing
  87. # these defaults.
  88. #
  89. DISTRO ?= "poky"
  90. # As an example of a subclass there is a "bleeding" edge policy configuration
  91. # where many versions are set to the absolute latest code from the upstream
  92. # source control systems. This is just mentioned here as an example, its not
  93. # useful to most new users.
  94. # DISTRO ?= "poky-bleeding"
  95.  
  96. #
  97. # Package Management configuration
  98. #
  99. # This variable lists which packaging formats to enable. Multiple package backends
  100. # can be enabled at once and the first item listed in the variable will be used
  101. # to generate the root filesystems.
  102. # Options are:
  103. # - 'package_deb' for debian style deb files
  104. # - 'package_ipk' for ipk files are used by opkg (a debian style embedded package manager)
  105. # - 'package_rpm' for rpm style packages
  106. # E.g.: PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk"
  107. # We default to rpm:
  108. PACKAGE_CLASSES ?= "package_rpm"
  109.  
  110. #
  111. # SDK target architecture
  112. #
  113. # This variable specifies the architecture to build SDK items for and means
  114. # you can build the SDK packages for architectures other than the machine you are
  115. # running the build on (i.e. building i686 packages on an x86_64 host).
  116. # Supported values are i686 and x86_64
  117. #SDKMACHINE ?= "i686"
  118.  
  119. #
  120. # Extra image configuration defaults
  121. #
  122. # The EXTRA_IMAGE_FEATURES variable allows extra packages to be added to the generated
  123. # images. Some of these options are added to certain image types automatically. The
  124. # variable can contain the following options:
  125. # "dbg-pkgs" - add -dbg packages for all installed packages
  126. # (adds symbol information for debugging/profiling)
  127. # "dev-pkgs" - add -dev packages for all installed packages
  128. # (useful if you want to develop against libs in the image)
  129. # "ptest-pkgs" - add -ptest packages for all ptest-enabled packages
  130. # (useful if you want to run the package test suites)
  131. # "tools-sdk" - add development tools (gcc, make, pkgconfig etc.)
  132. # "tools-debug" - add debugging tools (gdb, strace)
  133. # "eclipse-debug" - add Eclipse remote debugging support
  134. # "tools-profile" - add profiling tools (oprofile, lttng, valgrind)
  135. # "tools-testapps" - add useful testing tools (ts_print, aplay, arecord etc.)
  136. # "debug-tweaks" - make an image suitable for development
  137. # e.g. ssh root access has a blank password
  138. # There are other application targets that can be used here too, see
  139. # meta/classes/image.bbclass and meta/classes/core-image.bbclass for more details.
  140. # We default to enabling the debugging tweaks.
  141. EXTRA_IMAGE_FEATURES ?= "debug-tweaks"
  142.  
  143. #
  144. # Additional image features
  145. #
  146. # The following is a list of additional classes to use when building images which
  147. # enable extra features. Some available options which can be included in this variable
  148. # are:
  149. # - 'buildstats' collect build statistics
  150. # - 'image-mklibs' to reduce shared library files size for an image
  151. # - 'image-prelink' in order to prelink the filesystem image
  152. # NOTE: if listing mklibs & prelink both, then make sure mklibs is before prelink
  153. # NOTE: mklibs also needs to be explicitly enabled for a given image, see local.conf.extended
  154. USER_CLASSES ?= "buildstats image-mklibs image-prelink"
  155.  
  156. #
  157. # Runtime testing of images
  158. #
  159. # The build system can test booting virtual machine images under qemu (an emulator)
  160. # after any root filesystems are created and run tests against those images. To
  161. # enable this uncomment this line. See classes/testimage(-auto).bbclass for
  162. # further details.
  163. #TEST_IMAGE = "1"
  164. #
  165. # Interactive shell configuration
  166. #
  167. # Under certain circumstances the system may need input from you and to do this it
  168. # can launch an interactive shell. It needs to do this since the build is
  169. # multithreaded and needs to be able to handle the case where more than one parallel
  170. # process may require the user's attention. The default is iterate over the available
  171. # terminal types to find one that works.
  172. #
  173. # Examples of the occasions this may happen are when resolving patches which cannot
  174. # be applied, to use the devshell or the kernel menuconfig
  175. #
  176. # Supported values are auto, gnome, xfce, rxvt, screen, konsole (KDE 3.x only), none
  177. # Note: currently, Konsole support only works for KDE 3.x due to the way
  178. # newer Konsole versions behave
  179. #OE_TERMINAL = "auto"
  180. # By default disable interactive patch resolution (tasks will just fail instead):
  181. PATCHRESOLVE = "noop"
  182.  
  183. #
  184. # Disk Space Monitoring during the build
  185. #
  186. # Monitor the disk space during the build. If there is less that 1GB of space or less
  187. # than 100K inodes in any key build location (TMPDIR, DL_DIR, SSTATE_DIR), gracefully
  188. # shutdown the build. If there is less that 100MB or 1K inodes, perform a hard abort
  189. # of the build. The reason for this is that running completely out of space can corrupt
  190. # files and damages the build in ways which may not be easily recoverable.
  191. # It's necesary to monitor /tmp, if there is no space left the build will fail
  192. # with very exotic errors.
  193. BB_DISKMON_DIRS = "\
  194. STOPTASKS,${TMPDIR},1G,100K \
  195. STOPTASKS,${DL_DIR},1G,100K \
  196. STOPTASKS,${SSTATE_DIR},1G,100K \
  197. STOPTASKS,/tmp,100M,100K \
  198. ABORT,${TMPDIR},100M,1K \
  199. ABORT,${DL_DIR},100M,1K \
  200. ABORT,${SSTATE_DIR},100M,1K \
  201. ABORT,/tmp,10M,1K"
  202.  
  203. #
  204. # Shared-state files from other locations
  205. #
  206. # As mentioned above, shared state files are prebuilt cache data objects which can
  207. # used to accelerate build time. This variable can be used to configure the system
  208. # to search other mirror locations for these objects before it builds the data itself.
  209. #
  210. # This can be a filesystem directory, or a remote url such as http or ftp. These
  211. # would contain the sstate-cache results from previous builds (possibly from other
  212. # machines). This variable works like fetcher MIRRORS/PREMIRRORS and points to the
  213. # cache locations to check for the shared objects.
  214. # NOTE: if the mirror uses the same structure as SSTATE_DIR, you need to add PATH
  215. # at the end as shown in the examples below. This will be substituted with the
  216. # correct path within the directory structure.
  217. #SSTATE_MIRRORS ?= "\
  218. #file://.* http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \n \
  219. #file://.* file:///some/local/dir/sstate/PATH"
  220.  
  221.  
  222. #
  223. # Qemu configuration
  224. #
  225. # By default qemu will build with a builtin VNC server where graphical output can be
  226. # seen. The two lines below enable the SDL backend too. By default libsdl-native will
  227. # be built, if you want to use your host's libSDL instead of the minimal libsdl built
  228. # by libsdl-native then uncomment the ASSUME_PROVIDED line below.
  229. PACKAGECONFIG_append_pn-qemu-native = " sdl"
  230. PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
  231. #ASSUME_PROVIDED += "libsdl-native"
  232.  
  233. # CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to
  234. # track the version of this file when it was generated. This can safely be ignored if
  235. # this doesn't mean anything to you.
  236. CONF_VERSION = "1"
  237.  
  238. MACHINE = "raspberrypi3-64"
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement