Advertisement
Guest User

local.conf

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