adding-packages-generic.txt 17 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384
  1. // -*- mode:doc; -*-
  2. Infrastructure for packages with specific build systems
  3. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  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. ------------------------------
  12. 01: #############################################################
  13. 02: #
  14. 03: # libfoo
  15. 04: #
  16. 05: #############################################################
  17. 06: LIBFOO_VERSION = 1.0
  18. 07: LIBFOO_SOURCE = libfoo-$(LIBFOO_VERSION).tar.gz
  19. 08: LIBFOO_SITE = http://www.foosoftware.org/download
  20. 09: LIBFOO_LICENSE = GPLv3+
  21. 10: LIBFOO_LICENSE_FILES = COPYING
  22. 11: LIBFOO_INSTALL_STAGING = YES
  23. 12: LIBFOO_DEPENDENCIES = host-libaaa libbbb
  24. 13:
  25. 14: define LIBFOO_BUILD_CMDS
  26. 15: $(MAKE) CC="$(TARGET_CC)" LD="$(TARGET_LD)" -C $(@D) all
  27. 16: endef
  28. 17:
  29. 18: define LIBFOO_INSTALL_STAGING_CMDS
  30. 19: $(INSTALL) -D -m 0755 $(@D)/libfoo.a $(STAGING_DIR)/usr/lib/libfoo.a
  31. 20: $(INSTALL) -D -m 0644 $(@D)/foo.h $(STAGING_DIR)/usr/include/foo.h
  32. 21: $(INSTALL) -D -m 0755 $(@D)/libfoo.so* $(STAGING_DIR)/usr/lib
  33. 22: endef
  34. 23:
  35. 24: define LIBFOO_INSTALL_TARGET_CMDS
  36. 25: $(INSTALL) -D -m 0755 $(@D)/libfoo.so* $(TARGET_DIR)/usr/lib
  37. 26: $(INSTALL) -d -m 0755 $(TARGET_DIR)/etc/foo.d
  38. 27: endef
  39. 28:
  40. 29: define LIBFOO_DEVICES
  41. 30: /dev/foo c 666 0 0 42 0 - - -
  42. 31: endef
  43. 32:
  44. 33: define LIBFOO_PERMISSIONS
  45. 34: /bin/foo f 4755 0 0 - - - - -
  46. 35: endef
  47. 36:
  48. 37: $(eval $(generic-package))
  49. --------------------------------
  50. The Makefile begins on line 6 to 8 with metadata information: the
  51. version of the package (+LIBFOO_VERSION+), the name of the
  52. tarball containing the package (+LIBFOO_SOURCE+) and the
  53. Internet location at which the tarball can be downloaded
  54. (+LIBFOO_SITE+). All variables must start with the same prefix,
  55. +LIBFOO_+ in this case. This prefix is always the uppercased
  56. version of the package name (see below to understand where the package
  57. name is defined).
  58. On line 9, we specify that this package wants to install something to
  59. the staging space. This is often needed for libraries, since they must
  60. install header files and other development files in the staging space.
  61. This will ensure that the commands listed in the
  62. +LIBFOO_INSTALL_STAGING_CMDS+ variable will be executed.
  63. On line 10, we specify the list of dependencies this package relies
  64. on. These dependencies are listed in terms of lower-case package names,
  65. which can be packages for the target (without the +host-+
  66. prefix) or packages for the host (with the +host-+) prefix).
  67. Buildroot will ensure that all these packages are built and installed
  68. 'before' the current package starts its configuration.
  69. The rest of the Makefile defines what should be done at the different
  70. steps of the package configuration, compilation and installation.
  71. +LIBFOO_BUILD_CMDS+ tells what steps should be performed to
  72. build the package. +LIBFOO_INSTALL_STAGING_CMDS+ tells what
  73. steps should be performed to install the package in the staging space.
  74. +LIBFOO_INSTALL_TARGET_CMDS+ tells what steps should be
  75. performed to install the package in the target space.
  76. All these steps rely on the +$(@D)+ variable, which
  77. contains the directory where the source code of the package has been
  78. extracted.
  79. Finally, on line 35, we call the +generic-package+ which
  80. generates, according to the variables defined previously, all the
  81. Makefile code necessary to make your package working.
  82. [[generic-package-reference]]
  83. +generic-package+ Reference
  84. ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  85. There are two variants of the generic target. The +generic-package+ macro is
  86. used for packages to be cross-compiled for the target. The
  87. +host-generic-package+ macro is used for host packages, natively compiled
  88. for the host. It is possible to call both of them in a single +.mk+
  89. file: once to create the rules to generate a target
  90. package and once to create the rules to generate a host package:
  91. ----------------------
  92. $(eval $(generic-package))
  93. $(eval $(host-generic-package))
  94. ----------------------
  95. This might be useful if the compilation of the target package requires
  96. some tools to be installed on the host. If the package name is
  97. +libfoo+, then the name of the package for the target is also
  98. +libfoo+, while the name of the package for the host is
  99. +host-libfoo+. These names should be used in the DEPENDENCIES
  100. variables of other packages, if they depend on +libfoo+ or
  101. +host-libfoo+.
  102. The call to the +generic-package+ and/or +host-generic-package+ macro *must* be
  103. at the end of the +.mk+ file, after all variable definitions.
  104. For the target package, the +generic-package+ uses the variables defined by
  105. the .mk file and prefixed by the uppercased package name:
  106. +LIBFOO_*+. +host-generic-package+ uses the +HOST_LIBFOO_*+ variables. For
  107. 'some' variables, if the +HOST_LIBFOO_+ prefixed variable doesn't
  108. exist, the package infrastructure uses the corresponding variable
  109. prefixed by +LIBFOO_+. This is done for variables that are likely to
  110. have the same value for both the target and host packages. See below
  111. for details.
  112. The list of variables that can be set in a +.mk+ file to give metadata
  113. information is (assuming the package name is +libfoo+) :
  114. * +LIBFOO_VERSION+, mandatory, must contain the version of the
  115. package. Note that if +HOST_LIBFOO_VERSION+ doesn't exist, it is
  116. assumed to be the same as +LIBFOO_VERSION+. It can also be a
  117. revision number, branch or tag for packages that are fetched
  118. directly from their revision control system. +
  119. Examples: +
  120. +LIBFOO_VERSION = 0.1.2+ +
  121. +LIBFOO_VERSION = cb9d6aa9429e838f0e54faa3d455bcbab5eef057+ +
  122. +LIBFOO_VERSION = stable+
  123. * +LIBFOO_SOURCE+ may contain the name of the tarball of
  124. the package. If +HOST_LIBFOO_SOURCE+ is not specified, it
  125. defaults to +LIBFOO_SOURCE+. If none are specified, then
  126. the value is assumed to be
  127. +packagename-$(LIBFOO_VERSION).tar.gz+. +
  128. Example: +LIBFOO_SOURCE = foobar-$(LIBFOO_VERSION).tar.bz2+
  129. * +LIBFOO_PATCH+ may contain the name of a patch, that will be
  130. downloaded from the same location as the tarball indicated in
  131. +LIBFOO_SOURCE+. If +HOST_LIBFOO_PATCH+ is not specified, it
  132. defaults to +LIBFOO_PATCH+. Note that patches that are included
  133. in Buildroot itself use a different mechanism: all files of the
  134. form +<packagename>-*.patch+ present in the package directory inside
  135. Buildroot will be applied to the package after extraction (see
  136. xref:patch-policy[patching a package]).
  137. * +LIBFOO_SITE+ provides the location of the package, which can be a
  138. URL or a local filesystem path. HTTP, FTP and SCP are supported URL
  139. types for retrieving package tarballs. Git, Subversion, Mercurial,
  140. and Bazaar are supported URL types for retrieving packages directly
  141. from source code management systems. A filesystem path may be used
  142. to specify either a tarball or a directory containing the package
  143. source code. See +LIBFOO_SITE_METHOD+ below for more details on how
  144. retrieval works. +
  145. Note that SCP URLs should be of the form
  146. +scp://[user@]host:filepath+, and that filepath is relative to the
  147. user's home directory, so you may want to prepend the path with a
  148. slash for absolute paths:
  149. +scp://[user@]host:/absolutepath+. +
  150. If +HOST_LIBFOO_SITE+ is not specified, it defaults to
  151. +LIBFOO_SITE+.
  152. Examples: +
  153. +LIBFOO_SITE=http://www.libfoosoftware.org/libfoo+ +
  154. +LIBFOO_SITE=http://svn.xiph.org/trunk/Tremor/+ +
  155. +LIBFOO_SITE=git://github.com/kergoth/tslib.git+ +
  156. +LIBFOO_SITE=/opt/software/libfoo.tar.gz+ +
  157. +LIBFOO_SITE=$(TOPDIR)/../src/libfoo/+
  158. * +LIBFOO_SITE_METHOD+ determines the method used to fetch or copy the
  159. package source code. In many cases, Buildroot guesses the method
  160. from the contents of +LIBFOO_SITE+ and setting +LIBFOO_SITE_METHOD+
  161. is unnecessary. When +HOST_LIBFOO_SITE_METHOD+ is not specified, it
  162. defaults to the value of +LIBFOO_SITE_METHOD+. +
  163. The possible values of +LIBFOO_SITE_METHOD+ are:
  164. ** +wget+ for normal FTP/HTTP downloads of tarballs. Used by
  165. default when +LIBFOO_SITE+ begins with +http://+, +https://+ or
  166. +ftp://+.
  167. ** +scp+ for downloads of tarballs over SSH with scp. Used by
  168. default when +LIBFOO_SITE+ begins with +scp://+.
  169. ** +svn+ for retrieving source code from a Subversion repository.
  170. Used by default when +LIBFOO_SITE+ begins with +svn://+. When a
  171. +http://+ Subversion repository URL is specified in
  172. +LIBFOO_SITE+, one 'must' specify +LIBFOO_SITE_METHOD=svn+.
  173. Buildroot performs a checkout which is preserved as a tarball in
  174. the download cache; subsequent builds use the tarball instead of
  175. performing another checkout.
  176. ** +git+ for retrieving source code from a Git repository. Used by
  177. default when +LIBFOO_SITE+ begins with +git://+. The downloaded
  178. source code is cached as with the +svn+
  179. method.
  180. ** +hg+ for retrieving source code from a Mercurial repository. One
  181. 'must' specify +LIBFOO_SITE_METHOD=hg+ when +LIBFOO_SITE+
  182. contains a Mercurial repository URL. The downloaded source code
  183. is cached as with the +svn+ method.
  184. ** +bzr+ for retrieving source code from a Bazaar repository. Used
  185. by default when +LIBFOO_SITE+ begins with +bzr://+. The
  186. downloaded source code is cached as with the +svn+ method.
  187. ** +file+ for a local tarball. One should use this when
  188. +LIBFOO_SITE+ specifies a package tarball as a local filename.
  189. Useful for software that isn't available publicly or in version
  190. control.
  191. ** +local+ for a local source code directory. One should use this
  192. when +LIBFOO_SITE+ specifies a local directory path containing
  193. the package source code. Buildroot copies the contents of the
  194. source directory into the package's build directory.
  195. * +LIBFOO_DEPENDENCIES+ lists the dependencies (in terms of package
  196. name) that are required for the current target package to
  197. compile. These dependencies are guaranteed to be compiled and
  198. installed before the configuration of the current package starts. In
  199. a similar way, +HOST_LIBFOO_DEPENDENCIES+ lists the dependencies for
  200. the current host package.
  201. * +LIBFOO_INSTALL_STAGING+ can be set to +YES+ or +NO+ (default). If
  202. set to +YES+, then the commands in the +LIBFOO_INSTALL_STAGING_CMDS+
  203. variables are executed to install the package into the staging
  204. directory.
  205. * +LIBFOO_INSTALL_TARGET+ can be set to +YES+ (default) or +NO+. If
  206. set to +YES+, then the commands in the +LIBFOO_INSTALL_TARGET_CMDS+
  207. variables are executed to install the package into the target
  208. directory.
  209. * +LIBFOO_DEVICES+ lists the device files to be created by Buildroot
  210. when using the static device table. The syntax to use is the
  211. makedevs one. You can find some documentation for this syntax in the
  212. xref:makedev-syntax[]. This variable is optional.
  213. * +LIBFOO_PERMISSIONS+ lists the changes of permissions to be done at
  214. the end of the build process. The syntax is once again the makedevs one.
  215. You can find some documentation for this syntax in the xref:makedev-syntax[].
  216. This variable is optional.
  217. * +LIBFOO_LICENSE+ defines the license (or licenses) under which the package
  218. is released.
  219. This name will appear in the manifest file produced by +make legal-info+.
  220. If the license appears in xref:legal-info-list-licenses[the following list],
  221. use the same string to make the manifest file uniform.
  222. Otherwise, describe the license in a precise and concise way, avoiding
  223. ambiguous names such as +BSD+ which actually name a family of licenses.
  224. This variable is optional. If it is not defined, +unknown+ will appear in
  225. the +license+ field of the manifest file for this package.
  226. * +LIBFOO_LICENSE_FILES+ is a space-separated list of files in the package
  227. tarball that contain the license(s) under which the package is released.
  228. +make legal-info+ copies all of these files in the +legal-info+ directory.
  229. See xref:legal-info[] for more information.
  230. This variable is optional. If it is not defined, a warning will be produced
  231. to let you know, and +not saved+ will appear in the +license files+ field
  232. of the manifest file for this package.
  233. * +LIBFOO_REDISTRIBUTE+ can be set to +YES+ (default) or +NO+ to indicate if
  234. the package source code is allowed to be redistributed. Set it to +NO+ for
  235. non-opensource packages: Buildroot will not save the source code for this
  236. package when collecting the +legal-info+.
  237. The recommended way to define these variables is to use the following
  238. syntax:
  239. ----------------------
  240. LIBFOO_VERSION = 2.32
  241. ----------------------
  242. Now, the variables that define what should be performed at the
  243. different steps of the build process.
  244. * +LIBFOO_CONFIGURE_CMDS+ lists the actions to be performed to
  245. configure the package before its compilation.
  246. * +LIBFOO_BUILD_CMDS+ lists the actions to be performed to
  247. compile the package.
  248. * +HOST_LIBFOO_INSTALL_CMDS+ lists the actions to be performed
  249. to install the package, when the package is a host package. The
  250. package must install its files to the directory given by
  251. +$(HOST_DIR)+. All files, including development files such as
  252. headers should be installed, since other packages might be compiled
  253. on top of this package.
  254. * +LIBFOO_INSTALL_TARGET_CMDS+ lists the actions to be
  255. performed to install the package to the target directory, when the
  256. package is a target package. The package must install its files to
  257. the directory given by +$(TARGET_DIR)+. Only the files required for
  258. 'execution' of the package have to be
  259. installed. Header files, static libraries and documentation will be
  260. removed again when the target filesystem is finalized.
  261. * +LIBFOO_INSTALL_STAGING_CMDS+ lists the actions to be
  262. performed to install the package to the staging directory, when the
  263. package is a target package. The package must install its files to
  264. the directory given by +$(STAGING_DIR)+. All development files
  265. should be installed, since they might be needed to compile other
  266. packages.
  267. * +LIBFOO_CLEAN_CMDS+, lists the actions to perform to clean up
  268. the build directory of the package.
  269. * +LIBFOO_UNINSTALL_TARGET_CMDS+ lists the actions to
  270. uninstall the package from the target directory +$(TARGET_DIR)+
  271. * +LIBFOO_UNINSTALL_STAGING_CMDS+ lists the actions to
  272. uninstall the package from the staging directory +$(STAGING_DIR)+.
  273. * +LIBFOO_INSTALL_INIT_SYSV+ and +LIBFOO_INSTALL_INIT_SYSTEMD+ list the
  274. actions to install init scripts either for the systemV-like init systems
  275. (busybox, sysvinit, etc.) or for the systemd units. These commands
  276. will be run only when the relevant init system is installed (i.e. if
  277. systemd is selected as the init system in the configuration, only
  278. +LIBFOO_INSTALL_INIT_SYSTEMD+ will be run).
  279. The preferred way to define these variables is:
  280. ----------------------
  281. define LIBFOO_CONFIGURE_CMDS
  282. action 1
  283. action 2
  284. action 3
  285. endef
  286. ----------------------
  287. In the action definitions, you can use the following variables:
  288. * +$(@D)+, which contains the directory in which the package source
  289. code has been uncompressed.
  290. * +$(TARGET_CC)+, +$(TARGET_LD)+, etc. to get the target
  291. cross-compilation utilities
  292. * +$(TARGET_CROSS)+ to get the cross-compilation toolchain prefix
  293. * Of course the +$(HOST_DIR)+, +$(STAGING_DIR)+ and +$(TARGET_DIR)+
  294. variables to install the packages properly.
  295. The last feature of the generic infrastructure is the ability to add
  296. hooks. These define further actions to perform after existing steps.
  297. Most hooks aren't really useful for generic packages, since the +.mk+
  298. file already has full control over the actions performed in each step
  299. of the package construction. The hooks are more useful for packages
  300. using the autotools infrastructure described below. However, since
  301. they are provided by the generic infrastructure, they are documented
  302. here. The exception is +LIBFOO_POST_PATCH_HOOKS+. Patching the
  303. package and producing legal info are not user definable, so
  304. +LIBFOO_POST_PATCH_HOOKS+ and +LIBFOO_POST_LEGAL_INFO_HOOKS+ are
  305. useful for generic packages.
  306. The following hook points are available:
  307. * +LIBFOO_POST_DOWNLOAD_HOOKS+
  308. * +LIBFOO_POST_EXTRACT_HOOKS+
  309. * +LIBFOO_PRE_PATCH_HOOKS+
  310. * +LIBFOO_POST_PATCH_HOOKS+
  311. * +LIBFOO_PRE_CONFIGURE_HOOKS+
  312. * +LIBFOO_POST_CONFIGURE_HOOKS+
  313. * +LIBFOO_POST_BUILD_HOOKS+
  314. * +LIBFOO_POST_INSTALL_HOOKS+ (for host packages only)
  315. * +LIBFOO_POST_INSTALL_STAGING_HOOKS+ (for target packages only)
  316. * +LIBFOO_POST_INSTALL_TARGET_HOOKS+ (for target packages only)
  317. * +LIBFOO_POST_LEGAL_INFO_HOOKS+
  318. These variables are 'lists' of variable names containing actions to be
  319. performed at this hook point. This allows several hooks to be
  320. registered at a given hook point. Here is an example:
  321. ----------------------
  322. define LIBFOO_POST_PATCH_FIXUP
  323. action1
  324. action2
  325. endef
  326. LIBFOO_POST_PATCH_HOOKS += LIBFOO_POST_PATCH_FIXUP
  327. ----------------------