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