diff --git a/docs/buildroot.html b/docs/buildroot.html index 5b20e39f4c..5eff1baf64 100644 --- a/docs/buildroot.html +++ b/docs/buildroot.html @@ -808,767 +808,708 @@ config BR2_PACKAGE_LIBFOO categories). The files included there are sorted alphabetically per category and are NOT supposed to contain anything but the bare name of the package.

+ 
 source "package/libfoo/Config.in"
-

The .mk file

+

The .mk file

-

Finally, here's the hardest part. Create a file named - foo.mk. It describes how the package should be - downloaded, configured, built, installed, etc.

+

Finally, here's the hardest part. Create a file named + foo.mk. It describes how the package should be + downloaded, configured, built, installed, etc.

-

Depending on the package type, the .mk file must be - written in a different way, using different infrastructures:

+

Depending on the package type, the .mk file must be + written in a different way, using different infrastructures:

- - -

Makefile for generic packages : - tutorial

- - 
01: #############################################################
-02: #
-03: # libfoo
-04: #
-05: #############################################################
-06: LIBFOO_VERSION:=1.0
-07: LIBFOO_SOURCE:=libfoo-$(LIBFOO_VERSION).tar.gz
-08: LIBFOO_SITE:=http://www.foosoftware.org/download
-09: LIBFOO_INSTALL_STAGING=YES
-10: LIBFOO_DEPENDENCIES = host-libaaa libbbb
+
+01: #############################################################
+02: #
+03: # libfoo
+04: #
+05: #############################################################
+06: LIBFOO_VERSION = 1.0
+07: LIBFOO_SOURCE = libfoo-$(LIBFOO_VERSION).tar.gz
+08: LIBFOO_SITE = http://www.foosoftware.org/download
+09: LIBFOO_INSTALL_STAGING = YES
+10: LIBFOO_DEPENDENCIES = host-libaaa libbbb
 11: 
 12: define LIBFOO_BUILD_CMDS
-13:         $(MAKE) CC=$(TARGET_CC) LD=$(TARGET_LD) -C $(@D) all
+13: 	$(MAKE) CC=$(TARGET_CC) LD=$(TARGET_LD) -C $(@D) all
 14: endef
 15: 
 16: define LIBFOO_INSTALL_STAGING_CMDS
-17:         $(INSTALL) -D $(@D)/libfoo.a $(STAGING_DIR)/usr/lib/libfoo.a
-18:         $(INSTALL) -D $(@D)/foo.h $(STAGING_DIR)/usr/include/foo.h
-19:         cp -dpf $(@D)/libfoo.so* $(STAGING_DIR)/usr/lib
+17: 	$(INSTALL) -D -m 0755 $(@D)/libfoo.a $(STAGING_DIR)/usr/lib/libfoo.a
+18: 	$(INSTALL) -D -m 0644 $(@D)/foo.h $(STAGING_DIR)/usr/include/foo.h
+19: 	$(INSTALL) -D -m 0755 $(@D)/libfoo.so* $(STAGING_DIR)/usr/lib
 20: endef
 21: 
 22: define LIBFOO_INSTALL_TARGET_CMDS
-23:         cp -dpf $(@D)/libfoo.so* $(TARGET_DIR)/usr/lib
-24:         -$(STRIPCMP) $(STRIP_STRIP_UNNEEDED) $(TARGET_DIR)/isr/lib/libfoo.so*
+23: 	$(INSTALL) -D -m 0755 $(@D)/libfoo.so* $(TARGET_DIR)/usr/lib
+24: 	$(INSTALL) -d -m 0755 $(TARGET_DIR)/etc/foo.d
 25: endef
 26: 
-27: $(eval $(call GENTARGETS,package,libfoo))

+27: $(eval $(call GENTARGETS,package,libfoo))
+
-

The Makefile begins on line 6 to 8 by metadata informations: the - version of the package (LIBFOO_VERSION), the name of - the tarball containing the package (LIBFOO_SOURCE) and - the Internet location at which the tarball can be downloaded - (LIBFOO_SITE). All variables must start with the same - prefix, LIBFOO_ in this case. This prefix is always - the uppercased version of the package name (see below to understand - where the package name is defined).

+

The Makefile begins on line 6 to 8 by metadata informations: the + version of the package (LIBFOO_VERSION), the name of the + tarball containing the package (LIBFOO_SOURCE) and the + Internet location at which the tarball can be downloaded + (LIBFOO_SITE). All variables must start with the same prefix, + LIBFOO_ in this case. This prefix is always the uppercased + version of the package name (see below to understand where the package + name is defined).

-

On line 9, we specify that this package wants to install - something to the staging space. This is often needed for libraries - since they must install header files and other development files in - the staging space. This will ensure that the commands listed in the - LIBFOO_INSTALL_STAGING_CMDS variable will be - executed.

+

On line 9, we specify that this package wants to install something to + the staging space. This is often needed for libraries since they must + install header files and other development files in the staging space. + This will ensure that the commands listed in the + LIBFOO_INSTALL_STAGING_CMDS variable will be executed.

-

On line 10, we specify the list of dependencies this package - relies on. These dependencies are listed in terms of lower-case - package names, which can be packages for the target (without the - host- prefix) or packages for the host (with the - host-) prefix). Buildroot will ensure that all these - packages are built and installed before the current package - starts its configuration.

+

On line 10, we specify the list of dependencies this package relies + on. These dependencies are listed in terms of lower-case package names, + which can be packages for the target (without the host- + prefix) or packages for the host (with the host-) prefix). + Buildroot will ensure that all these packages are built and installed + before the current package starts its configuration.

-

The rest of the Makefile defines what should be done at the - different steps of the package configuration, compilation and - installation. LIBFOO_BUILD_CMDS tells what steps - should be performed to build the - package. LIBFOO_INSTALL_STAGING_CMDS tells what steps - should be performed to install the package in the staging - space. LIBFOO_INSTALL_TARGET_CMDS tells what steps - should be performed to install the package in the target space.

+

The rest of the Makefile defines what should be done at the different + steps of the package configuration, compilation and installation. + LIBFOO_BUILD_CMDS tells what steps should be performed to + build the package. LIBFOO_INSTALL_STAGING_CMDS tells what + steps should be performed to install the package in the staging space. + LIBFOO_INSTALL_TARGET_CMDS tells what steps should be + performed to install the package in the target space.

-

All these steps rely on the $(@D) variable, which - contains the directory where the source code of the package has - been extracted.

+

All these steps rely on the $(@D) variable, which + contains the directory where the source code of the package has been + extracted.

-

Finally, on line 27, we call the GENTARGETS which - generates, according to the variables defined previously, all the - Makefile code necessary to make your package working.

+

Finally, on line 27, we call the GENTARGETS which + generates, according to the variables defined previously, all the + Makefile code necessary to make your package working.

-

Makefile for generic packages : - reference

+

Makefile for generic packages : reference

-

The GENTARGETS macro takes three arguments:

+

The GENTARGETS macro takes three arguments:

- - -

For a given package, in a single .mk file, it is - possible to call GENTARGETS twice, once to create the rules to - generate a target package and once to create the rules to generate - a host package:

+

For a given package, in a single .mk file, it is + possible to call GENTARGETS twice, once to create the rules to generate + a target package and once to create the rules to generate a host package: + 

 $(eval $(call GENTARGETS,package,libfoo))
 $(eval $(call GENTARGETS,package,libfoo,host))
-

This might be useful if the compilation of the target package - requires some tools to be installed on the host. If the package - name is libfoo, then the name of the package for the - target is also libfoo, while the name of the package - for the host is host-libfoo. These names should be - used in the DEPENDENCIES variables of other packages if they depend - on libfoo or host-libfoo.

+

This might be useful if the compilation of the target package + requires some tools to be installed on the host. If the package name is + libfoo, then the name of the package for the target is also + libfoo, while the name of the package for the host is + host-libfoo. These names should be used in the DEPENDENCIES + variables of other packages if they depend on libfoo or + host-libfoo.

-

The call to the GENTARGETS macro must be at - the end of the .mk file, after all variable - definitions.

+

The call to the GENTARGETS macro must be at the + end of the .mk file, after all variable definitions.

-

For the target package, the GENTARGETS uses the - variables defined by the .mk file and prefixed by the uppercased - package name: LIBFOO_*. For the host package, it uses - the HOST_LIBFOO_*. For some variables, if the - HOST_LIBFOO_ prefixed variable doesn't exist, the - package infrastructure uses the corresponding variable prefixed by - LIBFOO_. This is done for variables that are likely to - have the same value for both the target and host packages. See - below for details.

+

For the target package, the GENTARGETS uses the + variables defined by the .mk file and prefixed by the uppercased package + name: LIBFOO_*. For the host package, it uses the + HOST_LIBFOO_*. For some variables, if the + HOST_LIBFOO_ prefixed variable doesn't exist, the package + infrastructure uses the corresponding variable prefixed by + LIBFOO_. This is done for variables that are likely to have + the same value for both the target and host packages. See below for + details.

-

The list of variables that can be set in a .mk file - to give metadata informations is (assuming the package name is - libfoo) :

+

The list of variables that can be set in a .mk file to + give metadata informations is (assuming the package name is + libfoo) :

- - -

The recommended way to define these variables is to use the - following syntax:

+

The recommended way to define these variables is to use the following + syntax:

 LIBFOO_VERSION=2.32
-

Now, the variables that define what should be performed at the - different steps of the build process.

+

Now, the variables that define what should be performed at the + different steps of the build process.

- - -

The preferred way to define these variables is:

+

The preferred way to define these variables is:

 define LIBFOO_CONFIGURE_CMDS
- action 1
- action 2
- action 3
-endef
+ action 1 + action 2 + action 3 +endef + -

In the action definitions, you can use the following - variables:

+

In the action definitions, you can use the following variables:

- +

The following hook points are available:

+ -

The last feature of the generic infrastructure is the ability - to add hook more actions after existing steps. These hooks aren't - really useful for generic packages, since the .mk - file already has full control over the actions performed in each - step of the package construction. The hooks are more useful for - packages using the autotools infrastructure described below. But - since they are provided by the generic infrastructure, they are - documented here.

+

This variables are lists of variable names containing actions + to be performed at this hook point. This allows several hooks to be + registered at a given hook point. Here is an example:

-

The following hook points are available:

- - - -

This variables are lists of variable names containing - actions to be performed at this hook point. This allows several - hooks to be registered at a given hook point. Here is an - example:

- - 
+
 define LIBFOO_POST_PATCH_FIXUP
-  action1
-  action2
+	action1
+	action2
 endef
 
 LIBFOO_POST_PATCH_HOOKS += LIBFOO_POST_PATCH_FIXUP
 

 
-   
Makefile for autotools-based
-   packages : tutorial

+   
Makefile for autotools-based packages : tutorial

 
-   
First, let's see how to write a .mk file for an
-   autotools-based package, with an example :

-
-
01: #############################################################
-02: #
-03: # foo
-04: #
-05: #############################################################
-06: 
-07: FOO_VERSION:=1.0
-08: FOO_SOURCE:=foo-$(FOO_VERSION).tar.gz
-09: FOO_SITE:=http://www.foosoftware.org/downloads
-10: FOO_INSTALL_STAGING = YES
-11: FOO_INSTALL_TARGET = YES
-12: FOO_CONF_OPT =  --enable-shared
-13: FOO_DEPENDENCIES = libglib2 host-pkg-config
-14: 
-15: $(eval $(call AUTOTARGETS,package,foo))

-
-    
On line 7, we declare the version of the package. On line 8 and
-    9, we declare the name of the tarball and the location of the
-    tarball on the Web. Buildroot will automatically download the
-    tarball from this location.

-
-    
On line 10, we tell Buildroot to install the package to the
-    staging directory. The staging directory, located in
-    output/staging/ is the directory where all the
-    packages are installed, including their development files, etc. By
-    default, packages are not installed to the staging directory,
-    since usually, only libraries need to be installed in the staging
-    directory: their development files are needed to compile other
-    libraries or applications depending on them. Also by default, when
-    staging installation is enabled, packages are installed in this
-    location using the make install command.

-
-    
On line 11, we tell Buildroot to also install the package to
-    the target directory. This directory contains what will become the
-    root filesystem running on the target. Usually, we try not to
-    install the documentation and to install stripped versions of the
-    binary. By default, target installation is enabled, so in fact,
-    this line is not strictly necessary. Also by default, packages are
-    installed in this location using the make
-    install-strip command.

-
-    
On line 12, we tell Buildroot to pass a custom configure
-    option, that will be passed to the ./configure script
-    before configuring and building the package.

-
-    
On line 13, we declare our dependencies, so that they are built
-    before the build process of our package starts.

-
-    
Finally, on line line 14, we invoke the
-    AUTOTARGETS macro that generates all the Makefile
-    rules that actually allows the package to be built.

-
-    
Makefile for autotools
-    packages : reference

-
-    
The main macro of the autotools package infrastructure is
-    AUTOTARGETS. It has the same number of arguments and
-    the same semantic as the GENTARGETS macro, which is
-    the main macro of the generic package infrastructure. For
-    autotools packages, the ability to have target and host packages
-    is also available (and is actually widely used).

-
-    
Just like the generic infrastructure, the autotools
-    infrastructure works by defining a number of variables before
-    calling the AUTOTARGETS macro.

-
-    
First, all the package meta-information variables that exist in
-    the generic infrastructure also exist in the autotools
-    infrastructure: LIBFOO_VERSION,
-    LIBFOO_SOURCE, LIBFOO_PATCH,
-    LIBFOO_SITE, LIBFOO_SUBDIR,
-    LIBFOO_DEPENDENCIES,
-    LIBFOO_INSTALL_STAGING,
-    LIBFOO_INSTALL_TARGET.

-
-    
A few additional variables, specific to the autotools
-    infrastructure, can also be defined. Many of them are only useful
-    in very specific cases, typical packages will therefore only use a
-    few of them.

-
-    
-
-    
With the autotools infrastructure, all the steps required to
-    build and install the packages are already defined, and they
-    generally work well for most autotools-based packages. However,
-    when required, it is still possible to customize what is done in
-    particular step:

-
-    
-
-    
Manual Makefile : tutorial

-
-    
NOTE: new manual makefiles should not be created, and
-    existing manual makefiles should be converted either to the
-    generic infrastructure or the autotools infrastructure. This
-    section is only kept to document the existing manual makefiles and
-    help understanding how they work.

+   
First, let's see how to write a .mk file for an 
+   autotools-based package, with an example :

 
 
-     1  #############################################################
-     2  #
-     3  # foo
-     4  #
-     5  #############################################################
-     6  FOO_VERSION:=1.0
-     7  FOO_SOURCE:=foo-$(FOO_VERSION).tar.gz
-     8  FOO_SITE:=http://www.foosoftware.org/downloads
-     9  FOO_DIR:=$(BUILD_DIR)/foo-$(FOO_VERSION)
-    10  FOO_BINARY:=foo
-    11  FOO_TARGET_BINARY:=usr/bin/foo
-    12
-    13  $(DL_DIR)/$(FOO_SOURCE):
-    14          $(call DOWNLOAD,$(FOO_SITE),$(FOO_SOURCE))
-    15
-    16  $(FOO_DIR)/.source: $(DL_DIR)/$(FOO_SOURCE)
-    17          $(ZCAT) $(DL_DIR)/$(FOO_SOURCE) | tar -C $(BUILD_DIR) $(TAR_OPTIONS) -
-    18          touch $@
-    19
-    20  $(FOO_DIR)/.configured: $(FOO_DIR)/.source
-    21          (cd $(FOO_DIR); rm -rf config.cache; \
-    22                  $(TARGET_CONFIGURE_OPTS) \
-    23                  $(TARGET_CONFIGURE_ARGS) \
-    24                  ./configure \
-    25                  --target=$(GNU_TARGET_NAME) \
-    26                  --host=$(GNU_TARGET_NAME) \
-    27                  --build=$(GNU_HOST_NAME) \
-    28                  --prefix=/usr \
-    29                  --sysconfdir=/etc \
-    30          )
-    31          touch $@
-    32
-    33  $(FOO_DIR)/$(FOO_BINARY): $(FOO_DIR)/.configured
-    34          $(MAKE) CC=$(TARGET_CC) -C $(FOO_DIR)
-    35
-    36  $(TARGET_DIR)/$(FOO_TARGET_BINARY): $(FOO_DIR)/$(FOO_BINARY)
-    37          $(MAKE) DESTDIR=$(TARGET_DIR) -C $(FOO_DIR) install-strip
-    38          rm -Rf $(TARGET_DIR)/usr/man
-    39
-    40  foo: uclibc ncurses $(TARGET_DIR)/$(FOO_TARGET_BINARY)
-    41
-    42  foo-source: $(DL_DIR)/$(FOO_SOURCE)
-    43
-    44  foo-clean:
-    45          $(MAKE) prefix=$(TARGET_DIR)/usr -C $(FOO_DIR) uninstall
-    46          -$(MAKE) -C $(FOO_DIR) clean
-    47
-    48  foo-dirclean:
-    49          rm -rf $(FOO_DIR)
-    50
-    51 #############################################################
-    52 #
-    53 # Toplevel Makefile options
-    54 #
-    55 #############################################################
-    56 ifeq ($(BR2_PACKAGE_FOO),y)
-    57 TARGETS+=foo
-    58 endif
-
+01: #############################################################
+02: #
+03: # libfoo
+04: #
+05: #############################################################
+06: LIBFOO_VERSION = 1.0
+07: LIBFOO_SOURCE = libfoo-$(LIBFOO_VERSION).tar.gz
+08: LIBFOO_SITE = http://www.foosoftware.org/download
+09: LIBFOO_INSTALL_STAGING = YES
+10: LIBFOO_INSTALL_TARGET = YES
+11: LIBFOO_CONF_OPT = --enable-shared
+12: LIBFOO_DEPENDENCIES = libglib2 host-pkg-config
+13:
+14: $(eval $(call AUTOTARGETS,package,libfoo))
 

 
-    
First of all, this Makefile example works for a package which comprises a single
-    binary executable. For other software, such as libraries or more
-    complex stuff with multiple binaries, it must be adapted. For examples look at
-    the other *.mk files in the package
-    directory. 

+    
On line 6, we declare the version of the package.

+    
+    
On line 7 and 8, we declare the name of the tarball and the location 
+    of the tarball on the Web. Buildroot will automatically download the 
+    tarball from this location.

+
+    
On line 9, we tell Buildroot to install the package to the staging 
+    directory. The staging directory, located in output/staging/
+    is the directory where all the packages are installed, including their 
+    development files, etc. By default, packages are not installed to the 
+    staging directory, since usually, only libraries need to be installed in 
+    the staging directory: their development files are needed to compile 
+    other libraries or applications depending on them. Also by default, when 
+    staging installation is enabled, packages are installed in this location 
+    using the make install command.

+
+    
On line 10, we tell Buildroot to also install the package to the 
+    target directory. This directory contains what will become the root 
+    filesystem running on the target. Usually, we try not to install header 
+    files and to install stripped versions of the binary. By default, target 
+    installation is enabled, so in fact, this line is not strictly 
+    necessary. Also by default, packages are installed in this location 
+    using the make install command.

+
+    
On line 11, we tell Buildroot to pass a custom configure option, that 
+    will be passed to the ./configure script before configuring 
+    and building the package.

+
+    
On line 12, we declare our dependencies, so that they are built 
+    before the build process of our package starts.

+
+    
Finally, on line line 14, we invoke the AUTOTARGETS 
+    macro that generates all the Makefile rules that actually allows the 
+    package to be built.

+
+    
Makefile for autotools packages : reference

+
+    
The main macro of the autotools package infrastructure is 
+    AUTOTARGETS. It has the same number of arguments and the 
+    same semantic as the GENTARGETS macro, which is the main 
+    macro of the generic package infrastructure. For autotools packages, the 
+    ability to have target and host packages is also available (and is 
+    actually widely used).

+
+    
Just like the generic infrastructure, the autotools infrastructure 
+    works by defining a number of variables before calling the 
+    AUTOTARGETS macro.

+
+    
First, all the package meta-information variables that exist in the 
+    generic infrastructure also exist in the autotools infrastructure: 
+    LIBFOO_VERSION, LIBFOO_SOURCE, 
+    LIBFOO_PATCH, LIBFOO_SITE, 
+    LIBFOO_SUBDIR, LIBFOO_DEPENDENCIES, 
+    LIBFOO_INSTALL_STAGING, LIBFOO_INSTALL_TARGET.

+
+    
A few additional variables, specific to the autotools infrastructure, 
+    can also be defined. Many of them are only useful in very specific 
+    cases, typical packages will therefore only use a few of them.

+
+    
+
+    
With the autotools infrastructure, all the steps required to build 
+    and install the packages are already defined, and they generally work 
+    well for most autotools-based packages. However, when required, it is 
+    still possible to customize what is done in particular step:

+
+    
+
+    
Manual Makefile : tutorial

+
+    
NOTE: new manual makefiles should not be created, and existing 
+    manual makefiles should be converted either to the generic 
+    infrastructure or the autotools infrastructure. This section is only 
+    kept to document the existing manual makefiles and help understanding 
+    how they work.

+
+
+01: #############################################################
+02: #
+03: # libfoo
+04: #
+05: #############################################################
+06: LIBFOO_VERSION:=1.0
+07: LIBFOO_SOURCE:=libfoo-$(LIBFOO_VERSION).tar.gz
+08: LIBFOO_SITE:=http://www.foosoftware.org/downloads
+09: LIBFOO_DIR:=$(BUILD_DIR)/foo-$(FOO_VERSION)
+10: LIBFOO_BINARY:=foo
+11: LIBFOO_TARGET_BINARY:=usr/bin/foo
+12:
+13: $(DL_DIR)/$(LIBFOO_SOURCE):
+14: 	$(call DOWNLOAD,$(LIBFOO_SITE),$(LIBFOO_SOURCE))
+15:
+16: $(LIBFOO_DIR)/.source: $(DL_DIR)/$(LIBFOO_SOURCE)
+17: 	$(ZCAT) $(DL_DIR)/$(LIBFOO_SOURCE) | tar -C $(BUILD_DIR) $(TAR_OPTIONS) -
+18: 	touch $@
+19:
+20: $(LIBFOO_DIR)/.configured: $(LIBFOO_DIR)/.source
+21: 	(cd $(LIBFOO_DIR); rm -rf config.cache; \
+22: 		$(TARGET_CONFIGURE_OPTS) \
+23: 		$(TARGET_CONFIGURE_ARGS) \
+24: 		./configure \
+25: 		--target=$(GNU_TARGET_NAME) \
+26: 		--host=$(GNU_TARGET_NAME) \
+27: 		--build=$(GNU_HOST_NAME) \
+28: 		--prefix=/usr \
+29: 		--sysconfdir=/etc \
+30: 	)
+31: 	touch $@
+32:
+33: $(LIBFOO_DIR)/$(LIBFOO_BINARY): $(LIBFOO_DIR)/.configured
+34: 	$(MAKE) CC=$(TARGET_CC) -C $(LIBFOO_DIR)
+35:
+36: $(TARGET_DIR)/$(LIBFOO_TARGET_BINARY): $(LIBFOO_DIR)/$(LIBFOO_BINARY)
+37: 	$(MAKE) DESTDIR=$(TARGET_DIR) -C $(LIBFOO_DIR) install-strip
+38: 	rm -Rf $(TARGET_DIR)/usr/man
+39:
+40: libfoo: uclibc ncurses $(TARGET_DIR)/$(LIBFOO_TARGET_BINARY)
+41:
+42: libfoo-source: $(DL_DIR)/$(LIBFOO_SOURCE)
+43:
+44: libfoo-clean:
+45: 	$(MAKE) prefix=$(TARGET_DIR)/usr -C $(LIBFOO_DIR) uninstall
+46: 	-$(MAKE) -C $(LIBFOO_DIR) clean
+47:
+48: libfoo-dirclean:
+49: 	rm -rf $(LIBFOO_DIR)
+50:
+51: #############################################################
+52: #
+53: # Toplevel Makefile options
+54: #
+55: #############################################################
+56: ifeq ($(BR2_PACKAGE_LIBFOO),y)
+57: TARGETS+=libfoo
+58: endif
+

+
+    
First of all, this Makefile example works for a package which 
+    comprises a single binary executable. For other software, such as 
+    libraries or more complex stuff with multiple binaries, it must be 
+    adapted. For examples look at the other *.mk files in the 
+    package directory.

 
     
At lines 6-11, a couple of useful variables are
     defined:

 
     
 
-     
  • FOO_TARGET_BINARY: The full path of the binary
-     inside the target filesystem. 
    • 
+    
    Lines 13-14 define a target that downloads 
+    the tarball from the remote site to the download directory 
+    (DL_DIR).
    
 
-    
+    
    Lines 16-18 define a target and associated 
+    rules that uncompress the downloaded tarball. As you can see, this 
+    target depends on the tarball file so that the previous target (lines 13-14) is called before executing the rules of the 
+    current target. Uncompressing is followed by touching a hidden 
+    file to mark the software as having been uncompressed. This trick is 
+    used everywhere in a Buildroot Makefile to split steps (download, 
+    uncompress, configure, compile, install) while still having correct 
+    dependencies.
    
 
-    
    Lines 13-14 define a target that downloads the
-    tarball from the remote site to the download directory
-    (DL_DIR). 
    
+    
    Lines 20-31 define a target and associated 
+    rules that configure the software. It depends on the previous target 
+    (the hidden .source file) so that we are sure the software 
+    has been uncompressed. In order to configure the package, it basically 
+    runs the well-known ./configure script. As we may be doing 
+    cross-compilation, target, host and 
+    build arguments are given. The prefix is also set to 
+    /usr, not because the software will be installed in 
+    /usr on your host system, but because the software will bin 
+    installed in  /usr on the target filesystem. Finally it 
+    creates a .configured file to mark the software as 
+    configured.
    
 
-    
    Lines 16-18 define a target and associated rules
-    that uncompress the downloaded tarball. As you can see, this target
-    depends on the tarball file so that the previous target (lines
-    13-14) is called before executing the rules of the
-    current target. Uncompressing is followed by touching a hidden file
-    to mark the software as having been uncompressed. This trick is
-    used everywhere in a Buildroot Makefile to split steps
-    (download, uncompress, configure, compile, install) while still
-    having correct dependencies. 
    
+    
    Lines 33-34 define a target and a rule that 
+    compile the software. This target will create the binary file in the 
+    compilation directory and depends on the software being already 
+    configured (hence the reference to the .configured file). 
+    It basically runs make inside the source directory.
    
 
-    
    Lines 20-31 define a target and associated rules
-    that configure the software. It depends on the previous target (the
-    hidden .source file) so that we are sure the software has
-    been uncompressed. In order to configure the package, it basically runs the
-    well-known ./configure script. As we may be doing
-    cross-compilation, target, host and
-    build arguments are given. The prefix is also set to
-    /usr, not because the software will be installed in
-    /usr on your host system, but because the software will
-    bin installed in /usr on the target
-    filesystem. Finally it creates a .configured file to
-    mark the software as configured. 
    
+    
    Lines 36-38 define a target and associated 
+    rules that install the software inside the target filesystem. They 
+    depend on the binary file in the source directory to make sure the 
+    software has been compiled. They use the install-strip 
+    target of the software Makefile by passing a 
+    DESTDIR argument so that the Makefile doesn't 
+    try to install the software in the host /usr but rather in 
+    the target /usr. After the installation, the 
+    /usr/man  directory inside the target filesystem is removed 
+    to save space. 
    
 
-    
    Lines 33-34 define a target and a rule that
-    compile the software. This target will create the binary file in the
-    compilation directory and depends on the software being already
-    configured (hence the reference to the .configured
-    file). It basically runs make inside the source
-    directory. 
    
+    
    Line 40 defines the main target of the 
+    software — the one that will be eventually be used by the top level 
+    Makefile to download, compile, and then install this 
+    package. This target should first of all depend on all needed 
+    dependencies of the software (in our example, uclibc and 
+    ncurses) and also depend on the final binary. This last dependency 
+    will call all previous dependencies in the correct order.
    
 
-    
    Lines 36-38 define a target and associated rules
-    that install the software inside the target filesystem. They depend on the
-    binary file in the source directory to make sure the software has
-    been compiled. They use the install-strip target of the
-    software Makefile by passing a DESTDIR
-    argument so that the Makefile doesn't try to install
-    the software in the host /usr but rather in the target
-    /usr. After the installation, the
-    /usr/man directory inside the target filesystem is
-    removed to save space. 
    
+    
    Line 42 defines a simple target that only 
+    downloads the code source. This is not used during normal operation of 
+    Buildroot, but is needed if you intend to download all required sources 
+    at once for later offline build. Note that if you add a new package 
+    providing a libfoo-source target is mandatory to 
+    support users that wish to do offline-builds. Furthermore it eases 
+    checking if all package-sources are downloadable.
    
 
-    
    Line 40 defines the main target of the software —
-    the one that will be eventually be used by the top level
-    Makefile to download, compile, and then install
-    this package. This target should first of all depend on all
-    needed dependencies of the software (in our example,
-    uclibc and ncurses) and also depend on the
-    final binary. This last dependency will call all previous
-    dependencies in the correct order. 
    
+    
    Lines 44-46 define a simple target to clean 
+    the software build by calling the Makefiles with the appropriate option. 
+    The -clean target should run make clean on 
+    $(BUILD_DIR)/package-version and MUST uninstall all files of the package 
+    from $(STAGING_DIR) and from $(TARGET_DIR).
    
 
-    
    Line 42 defines a simple target that only
-    downloads the code source. This is not used during normal operation of
-    Buildroot, but is needed if you intend to download all required sources at
-    once for later offline build. Note that if you add a new package providing
-    a foo-source target is mandatory to support
-    users that wish to do offline-builds. Furthermore it eases checking
-    if all package-sources are downloadable. 
    
+    
    Lines 48-49 define a simple target to 
+    completely remove the directory in which the software was uncompressed, 
+    configured and compiled. The -dirclean target MUST 
+    completely rm $(BUILD_DIR)/ package-version.
    
 
-    
    Lines 44-46 define a simple target to clean the
-    software build by calling the Makefiles with the appropriate option.
-    The -clean target should run make clean
-    on $(BUILD_DIR)/package-version and MUST uninstall all files of the
-    package from $(STAGING_DIR) and from $(TARGET_DIR). 
    
+    
    Lines 51-58 add the target libfoo 
+    to the list of targets to be compiled by Buildroot by first checking if 
+    the configuration option for this package has been enabled using the 
+    configuration tool. If so, it then "subscribes" this package 
+    to be compiled by adding the package to the TARGETS global variable.  
+    The name added to the TARGETS global variable is the name of this 
+    package's target, as defined on line 40, which 
+    is used by Buildroot to download, compile, and then install this package.
+    
    
 
-    
    Lines 48-49 define a simple target to completely
-    remove the directory in which the software was uncompressed, configured and
-    compiled. The -dirclean target MUST completely rm $(BUILD_DIR)/
-    package-version. 
    
+    
    Gettext integration and interaction with packages
    
 
-    
    Lines 51-58 add the target foo to
-    the list of targets to be compiled by Buildroot by first checking if
-    the configuration option for this package has been enabled
-    using the configuration tool. If so, it then "subscribes"
-    this package to be compiled by adding the package to the TARGETS
-    global variable.  The name added to the TARGETS global
-    variable is the name of this package's target, as defined on
-    line 40, which is used by Buildroot to download,
-    compile, and then install this package. 
    
+    
    Many packages that support internationalization use the gettext 
+    library. Dependency on this library are fairly complicated and therefore 
+    deserves a few explanations.
    
 
-    
    Gettext integration and
-    interaction with packages
    
+    
    The uClibc C library doesn't implement gettext functionality, 
+    therefore with this C library, a separate gettext must be compiled. On 
+    the other hand, the glibc C library does integrate its own 
+    gettext, and in this case, the separate gettext library should not be 
+    compiled, because it creates various kind of build failures.
    
 
-    
    Many packages that support internationalization use the gettext
-    library. Dependency on this library are fairly complicated and
-    therefore deserves a few explanations.
    
-
-    
    The uClibc C library doesn't implement gettext
-    functionality, therefore with this C library, a separate gettext
-    must be compiled. On the other hand, the glibc C library
-    does integrate its own gettext, and in this case, the separate
-    gettext library should not be compiled, because it creates various
-    kind of build failures.
    
-
-    
    Additionally, some packages (such as libglib2) do require
-    gettext unconditionally, while other packages (those who
-    support --disable-nls in general) only require
-    gettext when locale support is enabled.
    
+    
    Additionally, some packages (such as libglib2) do require gettext 
+    unconditionally, while other packages (those who support 
+    --disable-nls in general) only require gettext when locale 
+    support is enabled.
    
 
     
    Therefore, Buildroot defines two configuration options:
    
 
@@ -1576,64 +1517,52 @@ LIBFOO_POST_PATCH_HOOKS += LIBFOO_POST_PATCH_FIXUP
       
  • BR2_NEEDS_GETTEXT, which is true as soon as the
       toolchain doesn't provide its own gettext implementation
    • 
 
-      
  • BR2_NEEDS_GETTEXT_IF_LOCALE, which is true if
-      the toolchain doesn't provide its own gettext implementation and
-      if locale support is enabled
    • 
-
-    
+      
  • BR2_NEEDS_GETTEXT_IF_LOCALE, which is true if the 
+      toolchain doesn't provide its own gettext implementation and if locale 
+      support is enabled
    •  
 
     
    Therefore, packages that unconditionally need gettext should:
    
 
     
      
-      
    1. Use select BR2_PACKAGE_GETTEXT if
-      BR2_NEEDS_GETTEXT and possibly select
-      BR2_PACKAGE_LIBINTL if BR2_NEEDS_GETTEXT if libintl is
-      also needed
      2. 
+      
    2. Use select BR2_PACKAGE_GETTEXT if BR2_NEEDS_GETTEXT 
+      and possibly select BR2_PACKAGE_LIBINTL if BR2_NEEDS_GETTEXT 
+      if libintl is also needed
      3. 
 
-      
    3. Use $(if $(BR2_NEEDS_GETTEXT),gettext) in the
-      package DEPENDENCIES variable
      4. 
+      
    4. Use $(if $(BR2_NEEDS_GETTEXT),gettext) in the package 
+      DEPENDENCIES variable
      5. 
     
    
 
-    
    Packages that need gettext only when locale support is enabled
-    should:
    
+    
    Packages that need gettext only when locale support is enabled should:
+    
    
 
     
      
-      
    1. Use select BR2_PACKAGE_GETTEXT if
-      BR2_NEEDS_GETTEXT_IF_LOCALE and possibly select
-      BR2_PACKAGE_LIBINTL if BR2_NEEDS_GETTEXT_IF_LOCALE if
-      libintl is also needed
      2. 
+      
    2. Use 
+      select BR2_PACKAGE_GETTEXT if BR2_NEEDS_GETTEXT_IF_LOCALE 
+      and possibly 
+      select BR2_PACKAGE_LIBINTL if BR2_NEEDS_GETTEXT_IF_LOCALE 
+      if libintl is also needed
      3. 
 
-      
    3. Use $(if
-      $(BR2_NEEDS_GETTEXT_IF_LOCALE),gettext) in the
-      package DEPENDENCIES variable
      4. 
+      
    4. Use $(if $(BR2_NEEDS_GETTEXT_IF_LOCALE),gettext) in 
+      the package DEPENDENCIES variable
      5. 
     
    
 
     
    Conclusion
    
 
-    
    As you can see, adding a software package to Buildroot is simply a
-    matter of writing a Makefile using an  existing
-    example and modifying it according to the compilation process required by
-    the package. 
    
+    
    As you can see, adding a software package to Buildroot is simply a 
+    matter of writing a Makefile using an  existing example and modifying it 
+    according to the compilation process required by the package.
    
 
-    
    If you package software that might be useful for other people,
-    don't forget to send a patch to Buildroot developers!
    
+    
    If you package software that might be useful for other people, don't 
+    forget to send a patch to Buildroot developers!
    
 
-     
    Resources
    
+    
 
-    
    To learn more about Buildroot you can visit these
-    websites:
    
+    
    To learn more about Buildroot you can visit these websites:
    
 
     
   
-
-