adding-packages-generic.txt 20 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446
  1. // -*- mode:doc; -*-
  2. // vim: set syntax=asciidoc:
  3. Infrastructure for packages with specific build systems
  4. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  5. By 'packages with specific build systems' we mean all the packages
  6. whose build system is not one of the standard ones, such as
  7. 'autotools' or 'CMake'. This typically includes packages whose build
  8. system is based on hand-written Makefiles or shell scripts.
  9. [[generic-package-tutorial]]
  10. +generic-package+ Tutorial
  11. ^^^^^^^^^^^^^^^^^^^^^^^^^^
  12. ------------------------------
  13. 01: ################################################################################
  14. 02: #
  15. 03: # libfoo
  16. 04: #
  17. 05: ################################################################################
  18. 06:
  19. 07: LIBFOO_VERSION = 1.0
  20. 08: LIBFOO_SOURCE = libfoo-$(LIBFOO_VERSION).tar.gz
  21. 09: LIBFOO_SITE = http://www.foosoftware.org/download
  22. 10: LIBFOO_LICENSE = GPLv3+
  23. 11: LIBFOO_LICENSE_FILES = COPYING
  24. 12: LIBFOO_INSTALL_STAGING = YES
  25. 13: LIBFOO_CONFIG_SCRIPTS = libfoo-config
  26. 14: LIBFOO_DEPENDENCIES = host-libaaa libbbb
  27. 15:
  28. 16: define LIBFOO_BUILD_CMDS
  29. 17: $(MAKE) CC="$(TARGET_CC)" LD="$(TARGET_LD)" -C $(@D) all
  30. 18: endef
  31. 19:
  32. 20: define LIBFOO_INSTALL_STAGING_CMDS
  33. 21: $(INSTALL) -D -m 0755 $(@D)/libfoo.a $(STAGING_DIR)/usr/lib/libfoo.a
  34. 22: $(INSTALL) -D -m 0644 $(@D)/foo.h $(STAGING_DIR)/usr/include/foo.h
  35. 23: $(INSTALL) -D -m 0755 $(@D)/libfoo.so* $(STAGING_DIR)/usr/lib
  36. 24: endef
  37. 25:
  38. 26: define LIBFOO_INSTALL_TARGET_CMDS
  39. 27: $(INSTALL) -D -m 0755 $(@D)/libfoo.so* $(TARGET_DIR)/usr/lib
  40. 28: $(INSTALL) -d -m 0755 $(TARGET_DIR)/etc/foo.d
  41. 29: endef
  42. 30:
  43. 31: define LIBFOO_DEVICES
  44. 32: /dev/foo c 666 0 0 42 0 - - -
  45. 33: endef
  46. 34:
  47. 35: define LIBFOO_PERMISSIONS
  48. 36: /bin/foo f 4755 0 0 - - - - -
  49. 37: endef
  50. 38:
  51. 39: define LIBFOO_USERS
  52. 40: foo -1 libfoo -1 * - - - LibFoo daemon
  53. 41: endef
  54. 42:
  55. 43: $(eval $(generic-package))
  56. --------------------------------
  57. The Makefile begins on line 7 to 11 with metadata information: the
  58. version of the package (+LIBFOO_VERSION+), the name of the
  59. tarball containing the package (+LIBFOO_SOURCE+) (xz-ed tarball recommended)
  60. the Internet location at which the tarball can be downloaded from
  61. (+LIBFOO_SITE+), the license (+LIBFOO_LICENSE+) and file with the
  62. license text (+LIBFOO_LICENSE_FILES+). All variables must start with
  63. the same prefix, +LIBFOO_+ in this case. This prefix is always the
  64. uppercased version of the package name (see below to understand where
  65. the package name is defined).
  66. On line 12, we specify that this package wants to install something to
  67. the staging space. This is often needed for libraries, since they must
  68. install header files and other development files in the staging space.
  69. This will ensure that the commands listed in the
  70. +LIBFOO_INSTALL_STAGING_CMDS+ variable will be executed.
  71. On line 13, we specify that there is some fixing to be done to some
  72. of the 'libfoo-config' files that were installed during
  73. +LIBFOO_INSTALL_STAGING_CMDS+ phase.
  74. These *-config files are executable shell script files that are
  75. located in '$(STAGING_DIR)/usr/bin' directory and are executed
  76. by other 3rd party packages to find out the location and the linking
  77. flags of this particular package.
  78. The problem is that all these *-config files by default give wrong,
  79. host system linking flags that are unsuitable for cross-compiling.
  80. For example: '-I/usr/include' instead of '-I$(STAGING_DIR)/usr/include'
  81. or: '-L/usr/lib' instead of '-L$(STAGING_DIR)/usr/lib'
  82. So some sed magic is done to these scripts to make them give correct
  83. flags.
  84. The argument to be given to +LIBFOO_CONFIG_SCRIPTS+ is the file name(s)
  85. of the shell script(s) needing fixing. All these names are relative to
  86. '$(STAGING_DIR)/usr/bin' and if needed multiple names can be given.
  87. In addition, the scripts listed in +LIBFOO_CONFIG_SCRIPTS+ are removed
  88. from +$(TARGET_DIR)/usr/bin+, since they are not needed on the target.
  89. .Config script: 'divine' package
  90. ================================
  91. Package divine installs shell script '$(STAGING_DIR)/usr/bin/divine-config'.
  92. So its fixup would be:
  93. --------------------------------
  94. DIVINE_CONFIG_SCRIPTS = divine-config
  95. --------------------------------
  96. ================================
  97. .Config script: 'imagemagick' package:
  98. ================================
  99. Package imagemagick installs the following scripts:
  100. '$(STAGING_DIR)/usr/bin/{Magick,Magick++,MagickCore,MagickWand,Wand}-config'
  101. So it's fixup would be:
  102. --------------------------------
  103. IMAGEMAGICK_CONFIG_SCRIPTS = \
  104. Magick-config Magick++-config \
  105. MagickCore-config MagickWand-config Wand-config
  106. --------------------------------
  107. ================================
  108. On line 14, we specify the list of dependencies this package relies
  109. on. These dependencies are listed in terms of lower-case package names,
  110. which can be packages for the target (without the +host-+
  111. prefix) or packages for the host (with the +host-+) prefix).
  112. Buildroot will ensure that all these packages are built and installed
  113. 'before' the current package starts its configuration.
  114. The rest of the Makefile, lines 16..29, defines what should be done
  115. at the different steps of the package configuration, compilation and
  116. installation.
  117. +LIBFOO_BUILD_CMDS+ tells what steps should be performed to
  118. build the package. +LIBFOO_INSTALL_STAGING_CMDS+ tells what
  119. steps should be performed to install the package in the staging space.
  120. +LIBFOO_INSTALL_TARGET_CMDS+ tells what steps should be
  121. performed to install the package in the target space.
  122. All these steps rely on the +$(@D)+ variable, which
  123. contains the directory where the source code of the package has been
  124. extracted.
  125. On line 31..33, we define a device-node file used by this package
  126. (+LIBFOO_DEVICES+).
  127. On line 35..37, we define the permissions to set to specific files
  128. installed by this package (+LIBFOO_PERMISSIONS+).
  129. On lines 39..41, we define a user that is used by this package (eg.
  130. to run a daemon as non-root) (+LIBFOO_USERS+).
  131. Finally, on line 43, we call the +generic-package+ function, which
  132. generates, according to the variables defined previously, all the
  133. Makefile code necessary to make your package working.
  134. [[generic-package-reference]]
  135. +generic-package+ Reference
  136. ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  137. There are two variants of the generic target. The +generic-package+ macro is
  138. used for packages to be cross-compiled for the target. The
  139. +host-generic-package+ macro is used for host packages, natively compiled
  140. for the host. It is possible to call both of them in a single +.mk+
  141. file: once to create the rules to generate a target
  142. package and once to create the rules to generate a host package:
  143. ----------------------
  144. $(eval $(generic-package))
  145. $(eval $(host-generic-package))
  146. ----------------------
  147. This might be useful if the compilation of the target package requires
  148. some tools to be installed on the host. If the package name is
  149. +libfoo+, then the name of the package for the target is also
  150. +libfoo+, while the name of the package for the host is
  151. +host-libfoo+. These names should be used in the DEPENDENCIES
  152. variables of other packages, if they depend on +libfoo+ or
  153. +host-libfoo+.
  154. The call to the +generic-package+ and/or +host-generic-package+ macro *must* be
  155. at the end of the +.mk+ file, after all variable definitions.
  156. For the target package, the +generic-package+ uses the variables defined by
  157. the .mk file and prefixed by the uppercased package name:
  158. +LIBFOO_*+. +host-generic-package+ uses the +HOST_LIBFOO_*+ variables. For
  159. 'some' variables, if the +HOST_LIBFOO_+ prefixed variable doesn't
  160. exist, the package infrastructure uses the corresponding variable
  161. prefixed by +LIBFOO_+. This is done for variables that are likely to
  162. have the same value for both the target and host packages. See below
  163. for details.
  164. The list of variables that can be set in a +.mk+ file to give metadata
  165. information is (assuming the package name is +libfoo+) :
  166. * +LIBFOO_VERSION+, mandatory, must contain the version of the
  167. package. Note that if +HOST_LIBFOO_VERSION+ doesn't exist, it is
  168. assumed to be the same as +LIBFOO_VERSION+. It can also be a
  169. revision number, branch or tag for packages that are fetched
  170. directly from their revision control system. +
  171. Examples: +
  172. +LIBFOO_VERSION = 0.1.2+ +
  173. +LIBFOO_VERSION = cb9d6aa9429e838f0e54faa3d455bcbab5eef057+ +
  174. +LIBFOO_VERSION = stable+
  175. * +LIBFOO_SOURCE+ may contain the name of the tarball of
  176. the package. If +HOST_LIBFOO_SOURCE+ is not specified, it
  177. defaults to +LIBFOO_SOURCE+. If none are specified, then
  178. the value is assumed to be
  179. +packagename-$(LIBFOO_VERSION).tar.gz+. +
  180. Example: +LIBFOO_SOURCE = foobar-$(LIBFOO_VERSION).tar.bz2+
  181. * +LIBFOO_PATCH+ may contain a space-separated list of patch file
  182. names, that will be downloaded from the same location as the tarball
  183. indicated in +LIBFOO_SOURCE+, and then applied to the package source
  184. code. If +HOST_LIBFOO_PATCH+ is not specified, it defaults to
  185. +LIBFOO_PATCH+. Note that patches that are included in Buildroot
  186. itself use a different mechanism: all files of the form
  187. +<packagename>-*.patch+ present in the package directory inside
  188. Buildroot will be applied to the package after extraction (see
  189. xref:patch-policy[patching a package]). Finally, patches listed in
  190. the +LIBFOO_PATCH+ variable are applied _before_ the patches stored
  191. in the Buildroot package directory.
  192. * +LIBFOO_SITE+ provides the location of the package, which can be a
  193. URL or a local filesystem path. HTTP, FTP and SCP are supported URL
  194. types for retrieving package tarballs. Git, Subversion, Mercurial,
  195. and Bazaar are supported URL types for retrieving packages directly
  196. from source code management systems. There is a helper function to make
  197. it easier to download source tarballs from github (refer to
  198. xref:github-download-url[] for details). A filesystem path may be used
  199. to specify either a tarball or a directory containing the package
  200. source code. See +LIBFOO_SITE_METHOD+ below for more details on how
  201. retrieval works. +
  202. Note that SCP URLs should be of the form
  203. +scp://[user@]host:filepath+, and that filepath is relative to the
  204. user's home directory, so you may want to prepend the path with a
  205. slash for absolute paths:
  206. +scp://[user@]host:/absolutepath+. +
  207. If +HOST_LIBFOO_SITE+ is not specified, it defaults to
  208. +LIBFOO_SITE+.
  209. Examples: +
  210. +LIBFOO_SITE=http://www.libfoosoftware.org/libfoo+ +
  211. +LIBFOO_SITE=http://svn.xiph.org/trunk/Tremor/+ +
  212. +LIBFOO_SITE=/opt/software/libfoo.tar.gz+ +
  213. +LIBFOO_SITE=$(TOPDIR)/../src/libfoo/+
  214. * +LIBFOO_EXTRA_DOWNLOADS+ lists a number of additional files that
  215. Buildroot should download from +LIBFOO_SITE+ in addition to the main
  216. +LIBFOO_SOURCE+ (which usually is a tarball). Buildroot will not do
  217. anything with those additional files, except download files: it will
  218. be up to the package recipe to use them from +$(BR2_DL_DIR)+.
  219. * +LIBFOO_SITE_METHOD+ determines the method used to fetch or copy the
  220. package source code. In many cases, Buildroot guesses the method
  221. from the contents of +LIBFOO_SITE+ and setting +LIBFOO_SITE_METHOD+
  222. is unnecessary. When +HOST_LIBFOO_SITE_METHOD+ is not specified, it
  223. defaults to the value of +LIBFOO_SITE_METHOD+. +
  224. The possible values of +LIBFOO_SITE_METHOD+ are:
  225. ** +wget+ for normal FTP/HTTP downloads of tarballs. Used by
  226. default when +LIBFOO_SITE+ begins with +http://+, +https://+ or
  227. +ftp://+.
  228. ** +scp+ for downloads of tarballs over SSH with scp. Used by
  229. default when +LIBFOO_SITE+ begins with +scp://+.
  230. ** +svn+ for retrieving source code from a Subversion repository.
  231. Used by default when +LIBFOO_SITE+ begins with +svn://+. When a
  232. +http://+ Subversion repository URL is specified in
  233. +LIBFOO_SITE+, one 'must' specify +LIBFOO_SITE_METHOD=svn+.
  234. Buildroot performs a checkout which is preserved as a tarball in
  235. the download cache; subsequent builds use the tarball instead of
  236. performing another checkout.
  237. ** +cvs+ for retrieving source code from a CVS repository.
  238. Used by default when +LIBFOO_SITE+ begins with +cvs://+.
  239. The downloaded source code is cached as with the +svn+ method.
  240. Only anonymous pserver mode is supported.
  241. +LIBFOO_SITE+ 'must' contain the source URL as well as the remote
  242. repository directory. The module is the package name.
  243. +LIBFOO_VERSION+ is 'mandatory' and 'must' be a timestamp.
  244. ** +git+ for retrieving source code from a Git repository. Used by
  245. default when +LIBFOO_SITE+ begins with +git://+. The downloaded
  246. source code is cached as with the +svn+
  247. method.
  248. ** +hg+ for retrieving source code from a Mercurial repository. One
  249. 'must' specify +LIBFOO_SITE_METHOD=hg+ when +LIBFOO_SITE+
  250. contains a Mercurial repository URL. The downloaded source code
  251. is cached as with the +svn+ method.
  252. ** +bzr+ for retrieving source code from a Bazaar repository. Used
  253. by default when +LIBFOO_SITE+ begins with +bzr://+. The
  254. downloaded source code is cached as with the +svn+ method.
  255. ** +file+ for a local tarball. One should use this when
  256. +LIBFOO_SITE+ specifies a package tarball as a local filename.
  257. Useful for software that isn't available publicly or in version
  258. control.
  259. ** +local+ for a local source code directory. One should use this
  260. when +LIBFOO_SITE+ specifies a local directory path containing
  261. the package source code. Buildroot copies the contents of the
  262. source directory into the package's build directory.
  263. * +LIBFOO_DEPENDENCIES+ lists the dependencies (in terms of package
  264. name) that are required for the current target package to
  265. compile. These dependencies are guaranteed to be compiled and
  266. installed before the configuration of the current package starts. In
  267. a similar way, +HOST_LIBFOO_DEPENDENCIES+ lists the dependencies for
  268. the current host package.
  269. * +LIBFOO_INSTALL_STAGING+ can be set to +YES+ or +NO+ (default). If
  270. set to +YES+, then the commands in the +LIBFOO_INSTALL_STAGING_CMDS+
  271. variables are executed to install the package into the staging
  272. directory.
  273. * +LIBFOO_INSTALL_TARGET+ can be set to +YES+ (default) or +NO+. If
  274. set to +YES+, then the commands in the +LIBFOO_INSTALL_TARGET_CMDS+
  275. variables are executed to install the package into the target
  276. directory.
  277. * +LIBFOO_CONFIG_SCRIPTS+ lists the names of the files in
  278. '$(STAGING_DIR)/usr/bin' that need some special fixing to make them
  279. cross-compiling friendly. Multiple file names separated by space can
  280. be given and all are relative to '$(STAGING_DIR)/usr/bin'. The files
  281. listed in +LIBFOO_CONFIG_SCRIPTS+ are also removed from
  282. +$(TARGET_DIR)/usr/bin+ since they are not needed on the target.
  283. * +LIBFOO_DEVICES+ lists the device files to be created by Buildroot
  284. when using the static device table. The syntax to use is the
  285. makedevs one. You can find some documentation for this syntax in the
  286. xref:makedev-syntax[]. This variable is optional.
  287. * +LIBFOO_PERMISSIONS+ lists the changes of permissions to be done at
  288. the end of the build process. The syntax is once again the makedevs one.
  289. You can find some documentation for this syntax in the xref:makedev-syntax[].
  290. This variable is optional.
  291. * +LIBFOO_USERS+ lists the users to create for this package, if it installs
  292. a program you want to run as a specific user (eg. as a daemon, or as a
  293. cron-job). The syntax is similar in spirit to the makedevs one, and is
  294. described in the xref:makeuser-syntax[]. This variable is optional.
  295. * +LIBFOO_LICENSE+ defines the license (or licenses) under which the package
  296. is released.
  297. This name will appear in the manifest file produced by +make legal-info+.
  298. If the license appears in xref:legal-info-list-licenses[the following list],
  299. use the same string to make the manifest file uniform.
  300. Otherwise, describe the license in a precise and concise way, avoiding
  301. ambiguous names such as +BSD+ which actually name a family of licenses.
  302. This variable is optional. If it is not defined, +unknown+ will appear in
  303. the +license+ field of the manifest file for this package.
  304. * +LIBFOO_LICENSE_FILES+ is a space-separated list of files in the package
  305. tarball that contain the license(s) under which the package is released.
  306. +make legal-info+ copies all of these files in the +legal-info+ directory.
  307. See xref:legal-info[] for more information.
  308. This variable is optional. If it is not defined, a warning will be produced
  309. to let you know, and +not saved+ will appear in the +license files+ field
  310. of the manifest file for this package.
  311. * +LIBFOO_REDISTRIBUTE+ can be set to +YES+ (default) or +NO+ to indicate if
  312. the package source code is allowed to be redistributed. Set it to +NO+ for
  313. non-opensource packages: Buildroot will not save the source code for this
  314. package when collecting the +legal-info+.
  315. * +LIBFOO_FLAT_STACKSIZE+ defines the stack size of an application built into
  316. the FLAT binary format. The application stack size on the NOMMU architecture
  317. processors can't be enlarged at run time. The default stack size for the
  318. FLAT binary format is only 4k bytes. If the application consumes more stack,
  319. append the required number here.
  320. The recommended way to define these variables is to use the following
  321. syntax:
  322. ----------------------
  323. LIBFOO_VERSION = 2.32
  324. ----------------------
  325. Now, the variables that define what should be performed at the
  326. different steps of the build process.
  327. * +LIBFOO_EXTRACT_CMDS+ lists the actions to be performed to extract
  328. the package. This is generally not needed as tarballs are
  329. automatically handled by Buildroot. However, if the package uses a
  330. non-standard archive format, such as a ZIP or RAR file, or has a
  331. tarball with a non-standard organization, this variable allows to
  332. override the package infrastructure default behavior.
  333. * +LIBFOO_CONFIGURE_CMDS+ lists the actions to be performed to
  334. configure the package before its compilation.
  335. * +LIBFOO_BUILD_CMDS+ lists the actions to be performed to
  336. compile the package.
  337. * +HOST_LIBFOO_INSTALL_CMDS+ lists the actions to be performed
  338. to install the package, when the package is a host package. The
  339. package must install its files to the directory given by
  340. +$(HOST_DIR)+. All files, including development files such as
  341. headers should be installed, since other packages might be compiled
  342. on top of this package.
  343. * +LIBFOO_INSTALL_TARGET_CMDS+ lists the actions to be
  344. performed to install the package to the target directory, when the
  345. package is a target package. The package must install its files to
  346. the directory given by +$(TARGET_DIR)+. Only the files required for
  347. 'execution' of the package have to be
  348. installed. Header files, static libraries and documentation will be
  349. removed again when the target filesystem is finalized.
  350. * +LIBFOO_INSTALL_STAGING_CMDS+ lists the actions to be
  351. performed to install the package to the staging directory, when the
  352. package is a target package. The package must install its files to
  353. the directory given by +$(STAGING_DIR)+. All development files
  354. should be installed, since they might be needed to compile other
  355. packages.
  356. * +LIBFOO_INSTALL_INIT_SYSV+ and +LIBFOO_INSTALL_INIT_SYSTEMD+ list the
  357. actions to install init scripts either for the systemV-like init systems
  358. (busybox, sysvinit, etc.) or for the systemd units. These commands
  359. will be run only when the relevant init system is installed (i.e. if
  360. systemd is selected as the init system in the configuration, only
  361. +LIBFOO_INSTALL_INIT_SYSTEMD+ will be run).
  362. The preferred way to define these variables is:
  363. ----------------------
  364. define LIBFOO_CONFIGURE_CMDS
  365. action 1
  366. action 2
  367. action 3
  368. endef
  369. ----------------------
  370. In the action definitions, you can use the following variables:
  371. * +$(@D)+, which contains the directory in which the package source
  372. code has been uncompressed.
  373. * +$(TARGET_CC)+, +$(TARGET_LD)+, etc. to get the target
  374. cross-compilation utilities
  375. * +$(TARGET_CROSS)+ to get the cross-compilation toolchain prefix
  376. * Of course the +$(HOST_DIR)+, +$(STAGING_DIR)+ and +$(TARGET_DIR)+
  377. variables to install the packages properly.
  378. Finally, you can also use hooks. See xref:hooks[] for more information.