adding-packages-generic.txt 26 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568
  1. // -*- mode:doc; -*-
  2. // vim: set syntax=asciidoc:
  3. === Infrastructure for packages with specific build systems
  4. By 'packages with specific build systems' we mean all the packages
  5. whose build system is not one of the standard ones, such as
  6. 'autotools' or 'CMake'. This typically includes packages whose build
  7. system is based on hand-written Makefiles or shell scripts.
  8. [[generic-package-tutorial]]
  9. ==== +generic-package+ tutorial
  10. ------------------------------
  11. 01: ################################################################################
  12. 02: #
  13. 03: # libfoo
  14. 04: #
  15. 05: ################################################################################
  16. 06:
  17. 07: LIBFOO_VERSION = 1.0
  18. 08: LIBFOO_SOURCE = libfoo-$(LIBFOO_VERSION).tar.gz
  19. 09: LIBFOO_SITE = http://www.foosoftware.org/download
  20. 10: LIBFOO_LICENSE = GPL-3.0+
  21. 11: LIBFOO_LICENSE_FILES = COPYING
  22. 12: LIBFOO_INSTALL_STAGING = YES
  23. 13: LIBFOO_CONFIG_SCRIPTS = libfoo-config
  24. 14: LIBFOO_DEPENDENCIES = host-libaaa libbbb
  25. 15:
  26. 16: define LIBFOO_BUILD_CMDS
  27. 17: $(MAKE) $(TARGET_CONFIGURE_OPTS) -C $(@D) all
  28. 18: endef
  29. 19:
  30. 20: define LIBFOO_INSTALL_STAGING_CMDS
  31. 21: $(INSTALL) -D -m 0755 $(@D)/libfoo.a $(STAGING_DIR)/usr/lib/libfoo.a
  32. 22: $(INSTALL) -D -m 0644 $(@D)/foo.h $(STAGING_DIR)/usr/include/foo.h
  33. 23: $(INSTALL) -D -m 0755 $(@D)/libfoo.so* $(STAGING_DIR)/usr/lib
  34. 24: endef
  35. 25:
  36. 26: define LIBFOO_INSTALL_TARGET_CMDS
  37. 27: $(INSTALL) -D -m 0755 $(@D)/libfoo.so* $(TARGET_DIR)/usr/lib
  38. 28: $(INSTALL) -d -m 0755 $(TARGET_DIR)/etc/foo.d
  39. 29: endef
  40. 30:
  41. 31: define LIBFOO_USERS
  42. 32: foo -1 libfoo -1 * - - - LibFoo daemon
  43. 33: endef
  44. 34:
  45. 35: define LIBFOO_DEVICES
  46. 36: /dev/foo c 666 0 0 42 0 - - -
  47. 37: endef
  48. 38:
  49. 39: define LIBFOO_PERMISSIONS
  50. 40: /bin/foo f 4755 foo libfoo - - - - -
  51. 41: endef
  52. 42:
  53. 43: $(eval $(generic-package))
  54. --------------------------------
  55. The Makefile begins on line 7 to 11 with metadata information: the
  56. version of the package (+LIBFOO_VERSION+), the name of the
  57. tarball containing the package (+LIBFOO_SOURCE+) (xz-ed tarball recommended)
  58. the Internet location at which the tarball can be downloaded from
  59. (+LIBFOO_SITE+), the license (+LIBFOO_LICENSE+) and file with the
  60. license text (+LIBFOO_LICENSE_FILES+). All variables must start with
  61. the same prefix, +LIBFOO_+ in this case. This prefix is always the
  62. uppercased version of the package name (see below to understand where
  63. the package name is defined).
  64. On line 12, we specify that this package wants to install something to
  65. the staging space. This is often needed for libraries, since they must
  66. install header files and other development files in the staging space.
  67. This will ensure that the commands listed in the
  68. +LIBFOO_INSTALL_STAGING_CMDS+ variable will be executed.
  69. On line 13, we specify that there is some fixing to be done to some
  70. of the 'libfoo-config' files that were installed during
  71. +LIBFOO_INSTALL_STAGING_CMDS+ phase.
  72. These *-config files are executable shell script files that are
  73. located in '$(STAGING_DIR)/usr/bin' directory and are executed
  74. by other 3rd party packages to find out the location and the linking
  75. flags of this particular package.
  76. The problem is that all these *-config files by default give wrong,
  77. host system linking flags that are unsuitable for cross-compiling.
  78. For example: '-I/usr/include' instead of '-I$(STAGING_DIR)/usr/include'
  79. or: '-L/usr/lib' instead of '-L$(STAGING_DIR)/usr/lib'
  80. So some sed magic is done to these scripts to make them give correct
  81. flags.
  82. The argument to be given to +LIBFOO_CONFIG_SCRIPTS+ is the file name(s)
  83. of the shell script(s) needing fixing. All these names are relative to
  84. '$(STAGING_DIR)/usr/bin' and if needed multiple names can be given.
  85. In addition, the scripts listed in +LIBFOO_CONFIG_SCRIPTS+ are removed
  86. from +$(TARGET_DIR)/usr/bin+, since they are not needed on the target.
  87. .Config script: 'divine' package
  88. ================================
  89. Package divine installs shell script '$(STAGING_DIR)/usr/bin/divine-config'.
  90. So its fixup would be:
  91. --------------------------------
  92. DIVINE_CONFIG_SCRIPTS = divine-config
  93. --------------------------------
  94. ================================
  95. .Config script: 'imagemagick' package:
  96. ================================
  97. Package imagemagick installs the following scripts:
  98. '$(STAGING_DIR)/usr/bin/{Magick,Magick++,MagickCore,MagickWand,Wand}-config'
  99. So it's fixup would be:
  100. --------------------------------
  101. IMAGEMAGICK_CONFIG_SCRIPTS = \
  102. Magick-config Magick++-config \
  103. MagickCore-config MagickWand-config Wand-config
  104. --------------------------------
  105. ================================
  106. On line 14, we specify the list of dependencies this package relies
  107. on. These dependencies are listed in terms of lower-case package names,
  108. which can be packages for the target (without the +host-+
  109. prefix) or packages for the host (with the +host-+) prefix).
  110. Buildroot will ensure that all these packages are built and installed
  111. 'before' the current package starts its configuration.
  112. The rest of the Makefile, lines 16..29, defines what should be done
  113. at the different steps of the package configuration, compilation and
  114. installation.
  115. +LIBFOO_BUILD_CMDS+ tells what steps should be performed to
  116. build the package. +LIBFOO_INSTALL_STAGING_CMDS+ tells what
  117. steps should be performed to install the package in the staging space.
  118. +LIBFOO_INSTALL_TARGET_CMDS+ tells what steps should be
  119. performed to install the package in the target space.
  120. All these steps rely on the +$(@D)+ variable, which
  121. contains the directory where the source code of the package has been
  122. extracted.
  123. On lines 31..43, we define a user that is used by this package (e.g.
  124. to run a daemon as non-root) (+LIBFOO_USERS+).
  125. On line 35..37, we define a device-node file used by this package
  126. (+LIBFOO_DEVICES+).
  127. On line 39..41, we define the permissions to set to specific files
  128. installed by this package (+LIBFOO_PERMISSIONS+).
  129. Finally, on line 43, we call the +generic-package+ function, which
  130. generates, according to the variables defined previously, all the
  131. Makefile code necessary to make your package working.
  132. [[generic-package-reference]]
  133. ==== +generic-package+ reference
  134. There are two variants of the generic target. The +generic-package+ macro is
  135. used for packages to be cross-compiled for the target. The
  136. +host-generic-package+ macro is used for host packages, natively compiled
  137. for the host. It is possible to call both of them in a single +.mk+
  138. file: once to create the rules to generate a target
  139. package and once to create the rules to generate a host package:
  140. ----------------------
  141. $(eval $(generic-package))
  142. $(eval $(host-generic-package))
  143. ----------------------
  144. This might be useful if the compilation of the target package requires
  145. some tools to be installed on the host. If the package name is
  146. +libfoo+, then the name of the package for the target is also
  147. +libfoo+, while the name of the package for the host is
  148. +host-libfoo+. These names should be used in the DEPENDENCIES
  149. variables of other packages, if they depend on +libfoo+ or
  150. +host-libfoo+.
  151. The call to the +generic-package+ and/or +host-generic-package+ macro *must* be
  152. at the end of the +.mk+ file, after all variable definitions.
  153. For the target package, the +generic-package+ uses the variables defined by
  154. the .mk file and prefixed by the uppercased package name:
  155. +LIBFOO_*+. +host-generic-package+ uses the +HOST_LIBFOO_*+ variables. For
  156. 'some' variables, if the +HOST_LIBFOO_+ prefixed variable doesn't
  157. exist, the package infrastructure uses the corresponding variable
  158. prefixed by +LIBFOO_+. This is done for variables that are likely to
  159. have the same value for both the target and host packages. See below
  160. for details.
  161. The list of variables that can be set in a +.mk+ file to give metadata
  162. information is (assuming the package name is +libfoo+) :
  163. * +LIBFOO_VERSION+, mandatory, must contain the version of the
  164. package. Note that if +HOST_LIBFOO_VERSION+ doesn't exist, it is
  165. assumed to be the same as +LIBFOO_VERSION+. It can also be a
  166. revision number, branch or tag for packages that are fetched
  167. directly from their revision control system. +
  168. Examples: +
  169. +LIBFOO_VERSION = 0.1.2+ +
  170. +LIBFOO_VERSION = cb9d6aa9429e838f0e54faa3d455bcbab5eef057+ +
  171. +LIBFOO_VERSION = stable+
  172. * +LIBFOO_SOURCE+ may contain the name of the tarball of the package,
  173. which Buildroot will use to download the tarball from
  174. +LIBFOO_SITE+. If +HOST_LIBFOO_SOURCE+ is not specified, it defaults
  175. to +LIBFOO_SOURCE+. If none are specified, then the value is assumed
  176. to be +libfoo-$(LIBFOO_VERSION).tar.gz+. +
  177. Example: +LIBFOO_SOURCE = foobar-$(LIBFOO_VERSION).tar.bz2+
  178. * +LIBFOO_PATCH+ may contain a space-separated list of patch file
  179. names, that Buildroot will download and apply to the package source
  180. code. If an entry contains +://+, then Buildroot will assume it is a
  181. full URL and download the patch from this location. Otherwise,
  182. Buildroot will assume that the patch should be downloaded from
  183. +LIBFOO_SITE+. If +HOST_LIBFOO_PATCH+ is not specified, it defaults
  184. to +LIBFOO_PATCH+. Note that patches that are included in Buildroot
  185. itself use a different mechanism: all files of the form
  186. +*.patch+ present in the package directory inside
  187. Buildroot will be applied to the package after extraction (see
  188. xref:patch-policy[patching a package]). Finally, patches listed in
  189. the +LIBFOO_PATCH+ variable are applied _before_ the patches stored
  190. in the Buildroot package directory.
  191. * +LIBFOO_SITE+ provides the location of the package, which can be a
  192. URL or a local filesystem path. HTTP, FTP and SCP are supported URL
  193. types for retrieving package tarballs. In these cases don't include a
  194. trailing slash: it will be added by Buildroot between the directory
  195. and the filename as appropriate. Git, Subversion, Mercurial,
  196. and Bazaar are supported URL types for retrieving packages directly
  197. from source code management systems. There is a helper function to make
  198. it easier to download source tarballs from GitHub (refer to
  199. xref:github-download-url[] for details). A filesystem path may be used
  200. to specify either a tarball or a directory containing the package
  201. source code. See +LIBFOO_SITE_METHOD+ below for more details on how
  202. retrieval works. +
  203. Note that SCP URLs should be of the form
  204. +scp://[user@]host:filepath+, and that filepath is relative to the
  205. user's home directory, so you may want to prepend the path with a
  206. slash for absolute paths:
  207. +scp://[user@]host:/absolutepath+. +
  208. If +HOST_LIBFOO_SITE+ is not specified, it defaults to
  209. +LIBFOO_SITE+.
  210. Examples: +
  211. +LIBFOO_SITE=http://www.libfoosoftware.org/libfoo+ +
  212. +LIBFOO_SITE=http://svn.xiph.org/trunk/Tremor+ +
  213. +LIBFOO_SITE=/opt/software/libfoo.tar.gz+ +
  214. +LIBFOO_SITE=$(TOPDIR)/../src/libfoo+
  215. * +LIBFOO_DL_OPTS+ is a space-separated list of additional options to
  216. pass to the downloader. Useful for retrieving documents with
  217. server-side checking for user logins and passwords, or to use a proxy.
  218. All download methods valid for +LIBFOO_SITE_METHOD+ are supported;
  219. valid options depend on the download method (consult the man page
  220. for the respective download utilities).
  221. * +LIBFOO_EXTRA_DOWNLOADS+ is a space-separated list of additional
  222. files that Buildroot should download. If an entry contains +://+
  223. then Buildroot will assume it is a complete URL and will download
  224. the file using this URL. Otherwise, Buildroot will assume the file
  225. to be downloaded is located at +LIBFOO_SITE+. Buildroot will not do
  226. anything with those additional files, except download them: it will
  227. be up to the package recipe to use them from +$(LIBFOO_DL_DIR)+.
  228. * +LIBFOO_SITE_METHOD+ determines the method used to fetch or copy the
  229. package source code. In many cases, Buildroot guesses the method
  230. from the contents of +LIBFOO_SITE+ and setting +LIBFOO_SITE_METHOD+
  231. is unnecessary. When +HOST_LIBFOO_SITE_METHOD+ is not specified, it
  232. defaults to the value of +LIBFOO_SITE_METHOD+. +
  233. The possible values of +LIBFOO_SITE_METHOD+ are:
  234. ** +wget+ for normal FTP/HTTP downloads of tarballs. Used by
  235. default when +LIBFOO_SITE+ begins with +http://+, +https://+ or
  236. +ftp://+.
  237. ** +scp+ for downloads of tarballs over SSH with scp. Used by
  238. default when +LIBFOO_SITE+ begins with +scp://+.
  239. ** +svn+ for retrieving source code from a Subversion repository.
  240. Used by default when +LIBFOO_SITE+ begins with +svn://+. When a
  241. +http://+ Subversion repository URL is specified in
  242. +LIBFOO_SITE+, one 'must' specify +LIBFOO_SITE_METHOD=svn+.
  243. Buildroot performs a checkout which is preserved as a tarball in
  244. the download cache; subsequent builds use the tarball instead of
  245. performing another checkout.
  246. ** +cvs+ for retrieving source code from a CVS repository.
  247. Used by default when +LIBFOO_SITE+ begins with +cvs://+.
  248. The downloaded source code is cached as with the +svn+ method.
  249. Anonymous pserver mode is assumed otherwise explicitly defined
  250. on +LIBFOO_SITE+. Both
  251. +LIBFOO_SITE=cvs://libfoo.net:/cvsroot/libfoo+ and
  252. +LIBFOO_SITE=cvs://:ext:libfoo.net:/cvsroot/libfoo+
  253. are accepted, on the former anonymous pserver access mode is
  254. assumed.
  255. +LIBFOO_SITE+ 'must' contain the source URL as well as the remote
  256. repository directory. The module is the package name.
  257. +LIBFOO_VERSION+ is 'mandatory' and 'must' be a tag, a branch, or
  258. a date (e.g. "2014-10-20", "2014-10-20 13:45", "2014-10-20
  259. 13:45+01" see "man cvs" for further details).
  260. ** +git+ for retrieving source code from a Git repository. Used by
  261. default when +LIBFOO_SITE+ begins with +git://+. The downloaded
  262. source code is cached as with the +svn+
  263. method.
  264. ** +hg+ for retrieving source code from a Mercurial repository. One
  265. 'must' specify +LIBFOO_SITE_METHOD=hg+ when +LIBFOO_SITE+
  266. contains a Mercurial repository URL. The downloaded source code
  267. is cached as with the +svn+ method.
  268. ** +bzr+ for retrieving source code from a Bazaar repository. Used
  269. by default when +LIBFOO_SITE+ begins with +bzr://+. The
  270. downloaded source code is cached as with the +svn+ method.
  271. ** +file+ for a local tarball. One should use this when
  272. +LIBFOO_SITE+ specifies a package tarball as a local filename.
  273. Useful for software that isn't available publicly or in version
  274. control.
  275. ** +local+ for a local source code directory. One should use this
  276. when +LIBFOO_SITE+ specifies a local directory path containing
  277. the package source code. Buildroot copies the contents of the
  278. source directory into the package's build directory. Note that
  279. for +local+ packages, no patches are applied. If you need to
  280. still patch the source code, use +LIBFOO_POST_RSYNC_HOOKS+, see
  281. xref:hooks-rsync[].
  282. * +LIBFOO_GIT_SUBMODULES+ can be set to +YES+ to create an archive
  283. with the git submodules in the repository. This is only available
  284. for packages downloaded with git (i.e. when
  285. +LIBFOO_SITE_METHOD=git+). Note that we try not to use such git
  286. submodules when they contain bundled libraries, in which case we
  287. prefer to use those libraries from their own package.
  288. * +LIBFOO_STRIP_COMPONENTS+ is the number of leading components
  289. (directories) that tar must strip from file names on extraction.
  290. The tarball for most packages has one leading component named
  291. "<pkg-name>-<pkg-version>", thus Buildroot passes
  292. --strip-components=1 to tar to remove it.
  293. For non-standard packages that don't have this component, or
  294. that have more than one leading component to strip, set this
  295. variable with the value to be passed to tar. Default: 1.
  296. * +LIBFOO_EXCLUDES+ is a space-separated list of patterns to exclude
  297. when extracting the archive. Each item from that list is passed as
  298. a tar's +--exclude+ option. By default, empty.
  299. * +LIBFOO_DEPENDENCIES+ lists the dependencies (in terms of package
  300. name) that are required for the current target package to
  301. compile. These dependencies are guaranteed to be compiled and
  302. installed before the configuration of the current package starts. In
  303. a similar way, +HOST_LIBFOO_DEPENDENCIES+ lists the dependencies for
  304. the current host package.
  305. * +LIBFOO_EXTRACT_DEPENDENCIES+ lists the dependencies (in terms of
  306. package name) that are required for the current target package to be
  307. extracted. These dependencies are guaranteed to be compiled and
  308. installed before the extract step of the current package
  309. starts. This is only used internally by the package infrastructure,
  310. and should typically not be used directly by packages.
  311. * +LIBFOO_PATCH_DEPENDENCIES+ lists the dependencies (in terms of
  312. package name) that are required for the current package to be
  313. patched. These dependencies are guaranteed to be extracted and
  314. patched before the current package is patched. In a similar way,
  315. +HOST_LIBFOO_PATCH_DEPENDENCIES+ lists the dependencies for the
  316. current host package.
  317. This is seldom used; usually, +LIBFOO_DEPENDENCIES+ is what you
  318. really want to use.
  319. * +LIBFOO_PROVIDES+ lists all the virtual packages +libfoo+ is an
  320. implementation of. See xref:virtual-package-tutorial[].
  321. * +LIBFOO_INSTALL_STAGING+ can be set to +YES+ or +NO+ (default). If
  322. set to +YES+, then the commands in the +LIBFOO_INSTALL_STAGING_CMDS+
  323. variables are executed to install the package into the staging
  324. directory.
  325. * +LIBFOO_INSTALL_TARGET+ can be set to +YES+ (default) or +NO+. If
  326. set to +YES+, then the commands in the +LIBFOO_INSTALL_TARGET_CMDS+
  327. variables are executed to install the package into the target
  328. directory.
  329. * +LIBFOO_INSTALL_IMAGES+ can be set to +YES+ or +NO+ (default). If
  330. set to +YES+, then the commands in the +LIBFOO_INSTALL_IMAGES_CMDS+
  331. variable are executed to install the package into the images
  332. directory.
  333. * +LIBFOO_CONFIG_SCRIPTS+ lists the names of the files in
  334. '$(STAGING_DIR)/usr/bin' that need some special fixing to make them
  335. cross-compiling friendly. Multiple file names separated by space can
  336. be given and all are relative to '$(STAGING_DIR)/usr/bin'. The files
  337. listed in +LIBFOO_CONFIG_SCRIPTS+ are also removed from
  338. +$(TARGET_DIR)/usr/bin+ since they are not needed on the target.
  339. * +LIBFOO_DEVICES+ lists the device files to be created by Buildroot
  340. when using the static device table. The syntax to use is the
  341. makedevs one. You can find some documentation for this syntax in the
  342. xref:makedev-syntax[]. This variable is optional.
  343. * +LIBFOO_PERMISSIONS+ lists the changes of permissions to be done at
  344. the end of the build process. The syntax is once again the makedevs one.
  345. You can find some documentation for this syntax in the xref:makedev-syntax[].
  346. This variable is optional.
  347. * +LIBFOO_USERS+ lists the users to create for this package, if it installs
  348. a program you want to run as a specific user (e.g. as a daemon, or as a
  349. cron-job). The syntax is similar in spirit to the makedevs one, and is
  350. described in the xref:makeuser-syntax[]. This variable is optional.
  351. * +LIBFOO_LICENSE+ defines the license (or licenses) under which the package
  352. is released.
  353. This name will appear in the manifest file produced by +make legal-info+.
  354. If the license appears in https://spdx.org/licenses/[the SPDX License List],
  355. use the SPDX short identifier to make the manifest file uniform.
  356. Otherwise, describe the license in a precise and concise way, avoiding
  357. ambiguous names such as +BSD+ which actually name a family of licenses.
  358. This variable is optional. If it is not defined, +unknown+ will appear in
  359. the +license+ field of the manifest file for this package. +
  360. The expected format for this variable must comply with the following rules:
  361. ** If different parts of the package are released under different
  362. licenses, then +comma+ separate licenses (e.g. +`LIBFOO_LICENSE =
  363. GPL-2.0+, LGPL-2.1+`+). If there is clear distinction between which
  364. component is licensed under what license, then annotate the license
  365. with that component, between parenthesis (e.g. +`LIBFOO_LICENSE =
  366. GPL-2.0+ (programs), LGPL-2.1+ (libraries)`+).
  367. ** If the package is dual licensed, then separate licenses with the
  368. +or+ keyword (e.g. +`LIBFOO_LICENSE = AFL-2.1 or GPL-2.0+`+).
  369. * +LIBFOO_LICENSE_FILES+ is a space-separated list of files in the package
  370. tarball that contain the license(s) under which the package is released.
  371. +make legal-info+ copies all of these files in the +legal-info+ directory.
  372. See xref:legal-info[] for more information.
  373. This variable is optional. If it is not defined, a warning will be produced
  374. to let you know, and +not saved+ will appear in the +license files+ field
  375. of the manifest file for this package.
  376. * +LIBFOO_ACTUAL_SOURCE_TARBALL+ only applies to packages whose
  377. +LIBFOO_SITE+ / +LIBTOO_SOURCE+ pair points to an archive that does
  378. not actually contain source code, but binary code. This a very
  379. uncommon case, only known to apply to external toolchains which come
  380. already compiled, although theoretically it might apply to other
  381. packages. In such cases a separate tarball is usually available with
  382. the actual source code. Set +LIBFOO_ACTUAL_SOURCE_TARBALL+ to the
  383. name of the actual source code archive and Buildroot will download
  384. it and use it when you run +make legal-info+ to collect
  385. legally-relevant material. Note this file will not be downloaded
  386. during regular builds nor by +make source+.
  387. * +LIBFOO_ACTUAL_SOURCE_SITE+ provides the location of the actual
  388. source tarball. The default value is +LIBFOO_SITE+, so you don't
  389. need to set this variable if the binary and source archives are
  390. hosted on the same directory. If +LIBFOO_ACTUAL_SOURCE_TARBALL+ is
  391. not set, it doesn't make sense to define
  392. +LIBFOO_ACTUAL_SOURCE_SITE+.
  393. * +LIBFOO_REDISTRIBUTE+ can be set to +YES+ (default) or +NO+ to indicate if
  394. the package source code is allowed to be redistributed. Set it to +NO+ for
  395. non-opensource packages: Buildroot will not save the source code for this
  396. package when collecting the +legal-info+.
  397. * +LIBFOO_FLAT_STACKSIZE+ defines the stack size of an application built into
  398. the FLAT binary format. The application stack size on the NOMMU architecture
  399. processors can't be enlarged at run time. The default stack size for the
  400. FLAT binary format is only 4k bytes. If the application consumes more stack,
  401. append the required number here.
  402. * +LIBFOO_BIN_ARCH_EXCLUDE+ is a space-separated list of paths (relative
  403. to the target directory) to ignore when checking that the package
  404. installs correctly cross-compiled binaries. You seldom need to set this
  405. variable, unless the package installs binary blobs outside the default
  406. locations, `/lib/firmware`, `/usr/lib/firmware`, `/lib/modules`,
  407. `/usr/lib/modules`, and `/usr/share`, which are automatically excluded.
  408. The recommended way to define these variables is to use the following
  409. syntax:
  410. ----------------------
  411. LIBFOO_VERSION = 2.32
  412. ----------------------
  413. Now, the variables that define what should be performed at the
  414. different steps of the build process.
  415. * +LIBFOO_EXTRACT_CMDS+ lists the actions to be performed to extract
  416. the package. This is generally not needed as tarballs are
  417. automatically handled by Buildroot. However, if the package uses a
  418. non-standard archive format, such as a ZIP or RAR file, or has a
  419. tarball with a non-standard organization, this variable allows to
  420. override the package infrastructure default behavior.
  421. * +LIBFOO_CONFIGURE_CMDS+ lists the actions to be performed to
  422. configure the package before its compilation.
  423. * +LIBFOO_BUILD_CMDS+ lists the actions to be performed to
  424. compile the package.
  425. * +HOST_LIBFOO_INSTALL_CMDS+ lists the actions to be performed
  426. to install the package, when the package is a host package. The
  427. package must install its files to the directory given by
  428. +$(HOST_DIR)+. All files, including development files such as
  429. headers should be installed, since other packages might be compiled
  430. on top of this package.
  431. * +LIBFOO_INSTALL_TARGET_CMDS+ lists the actions to be
  432. performed to install the package to the target directory, when the
  433. package is a target package. The package must install its files to
  434. the directory given by +$(TARGET_DIR)+. Only the files required for
  435. 'execution' of the package have to be
  436. installed. Header files, static libraries and documentation will be
  437. removed again when the target filesystem is finalized.
  438. * +LIBFOO_INSTALL_STAGING_CMDS+ lists the actions to be
  439. performed to install the package to the staging directory, when the
  440. package is a target package. The package must install its files to
  441. the directory given by +$(STAGING_DIR)+. All development files
  442. should be installed, since they might be needed to compile other
  443. packages.
  444. * +LIBFOO_INSTALL_IMAGES_CMDS+ lists the actions to be performed to
  445. install the package to the images directory, when the package is a
  446. target package. The package must install its files to the directory
  447. given by +$(BINARIES_DIR)+. Only files that are binary images (aka
  448. images) that do not belong in the +TARGET_DIR+ but are necessary
  449. for booting the board should be placed here. For example, a package
  450. should utilize this step if it has binaries which would be similar
  451. to the kernel image, bootloader or root filesystem images.
  452. * +LIBFOO_INSTALL_INIT_SYSV+ and +LIBFOO_INSTALL_INIT_SYSTEMD+ list the
  453. actions to install init scripts either for the systemV-like init systems
  454. (busybox, sysvinit, etc.) or for the systemd units. These commands
  455. will be run only when the relevant init system is installed (i.e. if
  456. systemd is selected as the init system in the configuration, only
  457. +LIBFOO_INSTALL_INIT_SYSTEMD+ will be run).
  458. * +LIBFOO_HELP_CMDS+ lists the actions to print the package help, which
  459. is included to the main +make help+ output. These commands can print
  460. anything in any format.
  461. This is seldom used, as packages rarely have custom rules. *Do not use
  462. this variable*, unless you really know that you need to print help.
  463. The preferred way to define these variables is:
  464. ----------------------
  465. define LIBFOO_CONFIGURE_CMDS
  466. action 1
  467. action 2
  468. action 3
  469. endef
  470. ----------------------
  471. In the action definitions, you can use the following variables:
  472. * +$(LIBFOO_PKGDIR)+ contains the path to the directory containing the
  473. +libfoo.mk+ and +Config.in+ files. This variable is useful when it is
  474. necessary to install a file bundled in Buildroot, like a runtime
  475. configuration file, a splashscreen image...
  476. * +$(@D)+, which contains the directory in which the package source
  477. code has been uncompressed.
  478. * +$(LIBFOO_DL_DIR)+ contains the path to the directory where all the downloads
  479. made by Buildroot for +libfoo+ are stored in.
  480. * +$(TARGET_CC)+, +$(TARGET_LD)+, etc. to get the target
  481. cross-compilation utilities
  482. * +$(TARGET_CROSS)+ to get the cross-compilation toolchain prefix
  483. * Of course the +$(HOST_DIR)+, +$(STAGING_DIR)+ and +$(TARGET_DIR)+
  484. variables to install the packages properly.
  485. Finally, you can also use hooks. See xref:hooks[] for more information.