Advertisement
Guest User

Untitled

a guest
Aug 28th, 2012
75
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 9.68 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. # Parallelism Options
  16. #
  17. # These two options control how much parallelism BitBake should use. The first
  18. # option determines how many tasks bitbake should run in parallel:
  19. #
  20. BB_NUMBER_THREADS = "2"
  21. #
  22. # The second option controls how many processes make should run in parallel when
  23. # running compile tasks:
  24. #
  25. PARALLEL_MAKE = "-j 2"
  26. #
  27. # For a quad-core machine, BB_NUMBER_THREADS = "4", PARALLEL_MAKE = "-j 4" would
  28. # be appropriate for example.
  29.  
  30. #
  31. # Machine Selection
  32. #
  33. # You need to select a specific machine to target the build with. There are a selection
  34. # of emulated machines available which can boot and run in the QEMU emulator:
  35. #
  36. #MACHINE ?= "qemuarm"
  37. #MACHINE ?= "qemumips"
  38. #MACHINE ?= "qemuppc"
  39. #MACHINE ?= "qemux86"
  40. #MACHINE ?= "qemux86-64"
  41. #
  42. # There are also the following hardware board target machines included for
  43. # demonstration purposes:
  44. #
  45. #MACHINE ?= "atom-pc"
  46. #MACHINE ?= "beagleboard"
  47. #MACHINE ?= "mpc8315e-rdb"
  48. #MACHINE ?= "routerstationpro"
  49. #
  50. # This sets the default machine to be qemux86 if no other machine is selected:
  51. MACHINE ??= "pandaboard"
  52. #MACHINE=pandaboard
  53. BBMASK="meta-ti/recipes-misc"
  54. #
  55. # Where to place downloads
  56. #
  57. # During a first build the system will download many different source code tarballs
  58. # from various upstream projects. This can take a while, particularly if your network
  59. # connection is slow. These are all stored in DL_DIR. When wiping and rebuilding you
  60. # can preserve this directory to speed up this part of subsequent builds. This directory
  61. # is safe to share between multiple builds on the same machine too.
  62. #
  63. # The default is a downloads directory under TOPDIR which is the build directory.
  64. #
  65. #DL_DIR ?= "${TOPDIR}/downloads"
  66.  
  67. #
  68. # Where to place shared-state files
  69. #
  70. # BitBake has the capability to accelerate builds based on previously built output.
  71. # This is done using "shared state" files which can be thought of as cache objects
  72. # and this option determines where those files are placed.
  73. #
  74. # You can wipe out TMPDIR leaving this directory intact and the build would regenerate
  75. # from these files if no changes were made to the configuration. If changes were made
  76. # to the configuration, only shared state files where the state was still valid would
  77. # be used (done using checksums).
  78. #
  79. # The default is a sstate-cache directory under TOPDIR.
  80. #
  81. #SSTATE_DIR ?= "${TOPDIR}/sstate-cache"
  82.  
  83. #
  84. # Where to place the build output
  85. #
  86. # This option specifies where the bulk of the building work should be done and
  87. # where BitBake should place its temporary files and output. Keep in mind that
  88. # this includes the extraction and compilation of many applications and the toolchain
  89. # which can use Gigabytes of hard disk space.
  90. #
  91. # The default is a tmp directory under TOPDIR.
  92. #
  93. #TMPDIR = "${TOPDIR}/tmp"
  94.  
  95. #
  96. # Default policy config
  97. #
  98. # The distribution setting controls which policy settings are used as defaults.
  99. # The default value is fine for general Yocto project use, at least initially.
  100. # Ultimately when creating custom policy, people will likely end up subclassing
  101. # these defaults.
  102. #
  103. DISTRO ?= "poky"
  104. # As an example of a subclass there is a "bleeding" edge policy configuration
  105. # where many versions are set to the absolute latest code from the upstream
  106. # source control systems. This is just mentioned here as an example, its not
  107. # useful to most new users.
  108. # DISTRO ?= "poky-bleeding"
  109.  
  110. #
  111. # Package Management configuration
  112. #
  113. # This variable lists which packaging formats to enable. Multiple package backends
  114. # can be enabled at once and the first item listed in the variable will be used
  115. # to generate the root filesystems.
  116. # Options are:
  117. # - 'package_deb' for debian style deb files
  118. # - 'package_ipk' for ipk files are used by opkg (a debian style embedded package manager)
  119. # - 'package_rpm' for rpm style packages
  120. # E.g.: PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk"
  121. # We default to rpm:
  122. PACKAGE_CLASSES ?= "package_rpm"
  123.  
  124. #
  125. # SDK/ADT target architecture
  126. #
  127. # This variable specified the architecture to build SDK/ADT items for and means
  128. # you can build the SDK packages for architectures other than the machine you are
  129. # running the build on (i.e. building i686 packages on an x86_64 host._
  130. # Supported values are i686 and x86_64
  131. #SDKMACHINE ?= "i686"
  132.  
  133. #
  134. # Extra image configuration defaults
  135. #
  136. # The EXTRA_IMAGE_FEATURES variable allows extra packages to be added to the generated
  137. # images. Some of these options are added to certain image types automatically. The
  138. # variable can contain the following options:
  139. # "dbg-pkgs" - add -dbg packages for all installed packages
  140. # (adds symbol information for debugging/profiling)
  141. # "dev-pkgs" - add -dev packages for all installed packages
  142. # (useful if you want to develop against libs in the image)
  143. # "tools-sdk" - add development tools (gcc, make, pkgconfig etc.)
  144. # "tools-debug" - add debugging tools (gdb, strace)
  145. # "tools-profile" - add profiling tools (oprofile, exmap, lttng valgrind (x86 only))
  146. # "tools-testapps" - add useful testing tools (ts_print, aplay, arecord etc.)
  147. # "debug-tweaks" - make an image suitable for development
  148. # e.g. ssh root access has a blank password
  149. # There are other application targets that can be used here too, see
  150. # meta/classes/image.bbclass and meta/classes/core-image.bbclass for more details.
  151. # We default to enabling the debugging tweaks.
  152. EXTRA_IMAGE_FEATURES = "debug-tweaks"
  153.  
  154. #
  155. # Additional image features
  156. #
  157. # The following is a list of additional classes to use when building images which
  158. # enable extra features. Some available options which can be included in this variable
  159. # are:
  160. # - 'buildstats' collect build statistics
  161. # - 'image-mklibs' to reduce shared library files size for an image
  162. # - 'image-prelink' in order to prelink the filesystem image
  163. # - 'image-swab' to perform host system intrusion detection
  164. # NOTE: if listing mklibs & prelink both, then make sure mklibs is before prelink
  165. # NOTE: mklibs also needs to be explicitly enabled for a given image, see local.conf.extended
  166. USER_CLASSES ?= "buildstats image-mklibs image-prelink"
  167.  
  168. #
  169. # Runtime testing of images
  170. #
  171. # The build system can test booting virtual machine images under qemu (an emulator)
  172. # after any root filesystems are created and run tests against those images. To
  173. # enable this uncomment this line
  174. #IMAGETEST = "qemu"
  175. #
  176. # This variable controls which tests are run against virtual images if enabled
  177. # above. The following would enable bat, boot the test case under the sanity suite
  178. # and perform toolchain tests
  179. #TEST_SCEN = "sanity bat sanity:boot toolchain"
  180. #
  181. # Because of the QEMU booting slowness issue (see bug #646 and #618), the
  182. # autobuilder may suffer a timeout issue when running sanity tests. We introduce
  183. # the variable TEST_SERIALIZE here to reduce the time taken by the sanity tests.
  184. # It is set to 1 by default, which will boot the image and run cases in the same
  185. # image without rebooting or killing the machine instance. If it is set to 0, the
  186. # image will be copied and tested for each case, which will take longer but be
  187. # more precise.
  188. #TEST_SERIALIZE = "1"
  189.  
  190. #
  191. # Interactive shell configuration
  192. #
  193. # Under certain circumstances the system may need input from you and to do this it
  194. # can launch an interactive shell. It needs to do this since the build is
  195. # multithreaded and needs to be able to handle the case where more than one parallel
  196. # process may require the user's attention. The default is iterate over the available
  197. # terminal types to find one that works.
  198. #
  199. # Examples of the occasions this may happen are when resolving patches which cannot
  200. # be applied, to use the devshell or the kernel menuconfig
  201. #
  202. # Supported values are auto, gnome, xfce, rxvt, screen, konsole (KDE 3.x only), none
  203. # Note: currently, Konsole support only works for KDE 3.x due to the way
  204. # newer Konsole versions behave
  205. #OE_TERMINAL = "auto"
  206. # By default disable interactive patch resolution (tasks will just fail instead):
  207. PATCHRESOLVE = "noop"
  208.  
  209. #
  210. # Shared-state files from other locations
  211. #
  212. # As mentioned above, shared state files are prebuilt cache data objects which can
  213. # used to accelerate build time. This variable can be used to configure the system
  214. # to search other mirror locations for these objects before it builds the data itself.
  215. #
  216. # This can be a filesystem directory, or a remote url such as http or ftp. These
  217. # would contain the sstate-cache results from previous builds (possibly from other
  218. # machines). This variable works like fetcher MIRRORS/PREMIRRORS and points to the
  219. # cache locations to check for the shared objects.
  220. #SSTATE_MIRRORS ?= "\
  221. #file://.* http://someserver.tld/share/sstate/ \n \
  222. #file://.* file:///some/local/dir/sstate/"
  223.  
  224. # CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to
  225. # track the version of this file when it was generated. This can safely be ignored if
  226. # this doesn't mean anything to you.
  227. CONF_VERSION = "1"
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement