docs/manual/adding-packages-generic.txt

11 [[generic-package-tutorial]]
13 ==== +generic-package+ tutorial
58 43: $(eval $(generic-package))
62 version of the package (+LIBFOO_VERSION+), the name of the
63 tarball containing the package (+LIBFOO_SOURCE+) (xz-ed tarball recommended)
68 uppercased version of the package name (see below to understand where
69 the package name is defined).
71 On line 12, we specify that this package wants to install something to
83 flags of this particular package.
100 .Config script: 'divine' package
102 Package divine installs shell script '$(STAGING_DIR)/usr/bin/divine-config'.
111 .Config script: 'imagemagick' package:
113 Package imagemagick installs the following scripts:
125 On line 14, we specify the list of dependencies this package relies
126 on. These dependencies are listed in terms of lower-case package names,
130 'before' the current package starts its configuration.
133 at the different steps of the package configuration, compilation and
136 build the package. +LIBFOO_INSTALL_STAGING_CMDS+ tells what
137 steps should be performed to install the package in the staging space.
139 performed to install the package in the target space.
142 contains the directory where the source code of the package has been
145 On lines 31..33, we define a user that is used by this package (e.g.
148 On line 35..37, we define a device-node file used by this package
152 installed by this package (+LIBFOO_PERMISSIONS+).
154 Finally, on line 43, we call the +generic-package+ function, which
156 Makefile code necessary to make your package working.
158 [[generic-package-reference]]
160 ==== +generic-package+ reference
162 There are two variants of the generic target. The +generic-package+ macro is
164 +host-generic-package+ macro is used for host packages, natively compiled
167 package and once to create the rules to generate a host package:
170 $(eval $(generic-package))
171 $(eval $(host-generic-package))
174 This might be useful if the compilation of the target package requires
175 some tools to be installed on the host. If the package name is
176 +libfoo+, then the name of the package for the target is also
177 +libfoo+, while the name of the package for the host is
182 The call to the +generic-package+ and/or +host-generic-package+ macro
184 The call to +host-generic-package+ *must* be after the call to
185 +generic-package+, if any.
187 For the target package, the +generic-package+ uses the variables defined by
188 the .mk file and prefixed by the uppercased package name:
189 +LIBFOO_*+. +host-generic-package+ uses the +HOST_LIBFOO_*+ variables. For
191 exist, the package infrastructure uses the corresponding variable
197 information is (assuming the package name is +libfoo+) :
200   package. Note that if +HOST_LIBFOO_VERSION+ doesn't exist, it is
222 * +LIBFOO_SOURCE+ may contain the name of the tarball of the package,
230   names, that Buildroot will download and apply to the package source
237   +*.patch+ present in the package directory inside
238   Buildroot will be applied to the package after extraction (see
239   xref:patch-policy[patching a package]). Finally, patches listed in
241   in the Buildroot package directory.
243 * +LIBFOO_SITE+ provides the location of the package, which can be a
245   types for retrieving package tarballs. In these cases don't include a
252   to specify either a tarball or a directory containing the package
281   be up to the package recipe to use them from +$(LIBFOO_DL_DIR)+.
284   package source code. In many cases, Buildroot guesses the method
311      repository directory. The module is the package name.
327      +LIBFOO_SITE+ specifies a package tarball as a local filename.
332      the package source code. Buildroot copies the contents of the
333      source directory into the package's build directory. Note that
343   prefer to use those libraries from their own package.
358 * +LIBFOO_DEPENDENCIES+ lists the dependencies (in terms of package
359   name) that are required for the current target package to
361   installed before the configuration of the current package starts.
363   not force a rebuild of the current package. In a similar way,
365   host package.
368   package name) that are required for the current target package to be
370   installed before the extract step of the current package
371   starts. This is only used internally by the package infrastructure,
375   package name) that are required for the current package to be
377   patched (but not necessarily built) before the current package is
379   the dependencies for the current host package.
384   implementation of. See xref:virtual-package-tutorial[].
388   variables are executed to install the package into the staging
393   variables are executed to install the package into the target
398   variable are executed to install the package into the images
418 * +LIBFOO_USERS+ lists the users to create for this package, if it installs
423 * +LIBFOO_LICENSE+ defines the license (or licenses) under which the package
431   the +license+ field of the manifest file for this package. +
433   ** If different parts of the package are released under different
443   ** If the package is dual licensed, then separate licenses with the
446 * +LIBFOO_LICENSE_FILES+ is a space-separated list of files in the package
447   tarball that contain the license(s) under which the package is released.
452   of the manifest file for this package.
474   the package source code is allowed to be redistributed. Set it to +NO+ for
476   package when collecting the +legal-info+.
485   to the target directory) to ignore when checking that the package
487   variable, unless the package installs binary blobs outside the default
493   package. This is typically used when the CVE is fixed by a patch in
494   the package, or when the CVE for some reason does not affect the
495   Buildroot package. A Makefile comment must always precede the
506   package to define its https://nvd.nist.gov/products/cpe[CPE
529 If any of those variables is defined, then the generic package
530 infrastructure assumes the package provides valid CPE information. In
531 this case, the generic package infrastructure will define
534 For a host package, if its +LIBFOO_CPE_ID_*+ variables are not
536 corresponding target package.
549   the package. This is generally not needed as tarballs are
550   automatically handled by Buildroot. However, if the package uses a
553   override the package infrastructure default behavior.
556   configure the package before its compilation.
559   compile the package.
562   to install the package, when the package is a host package. The
563   package must install its files to the directory given by
566   on top of this package.
569   performed to install the package to the target directory, when the
570   package is a target package. The package must install its files to
572   'execution' of the package have to be
577   performed to install the package to the staging directory, when the
578   package is a target package. The package must install its files to
584   install the package to the images directory, when the package is a
585   target package. The package must install its files to the directory
588   for booting the board should be placed here. For example, a package
607 * +LIBFOO_HELP_CMDS+ lists the actions to print the package help, which
614   options that are needed to build and use this package, and without
615   which the package is fundamentally broken. This shall be a set of
618   This is seldom used, as package usually have no strict requirements on
638 * +$(@D)+, which contains the directory in which the package source
652   _per-package directory_ support is used, in which case they point to
653   the current package _host_, _staging_ and _target_ directories. In
654   both cases, it doesn't make any difference from the package point of
657   about _per-package directory_ support.