From cc98404a318dd8e1f102eec8a6ec493299008359 Mon Sep 17 00:00:00 2001 From: Martin Banky Date: Tue, 12 Oct 2010 15:17:55 -0700 Subject: [PATCH] buildroot.html: Fix grammer and punctuation Also, clarified some of the information given. Signed-off-by: Martin Banky Signed-off-by: Peter Korsgaard --- docs/buildroot.html | 241 ++++++++++++++++++++++---------------------- 1 file changed, 123 insertions(+), 118 deletions(-) diff --git a/docs/buildroot.html b/docs/buildroot.html index 5eff1baf64..ae0b524a80 100644 --- a/docs/buildroot.html +++ b/docs/buildroot.html @@ -94,7 +94,7 @@

You might wonder why such a tool is needed when you can compile gcc, binutils, uClibc and all - the other tools by hand. Of course doing so is possible. But, dealing with + the other tools by hand. Of course doing so is possible but, dealing with all of the configure options and problems of every gcc or binutils version is very time-consuming and uninteresting. Buildroot automates this process through the use of Makefiles and has a @@ -111,7 +111,7 @@

Buildroot releases are made approximately every 3 months. Direct Git access and daily snapshots are also - available if you want more bleeding edge.

+ available, if you want more bleeding edge.

Releases are available at http://buildroot.net/downloads/.

@@ -121,7 +121,7 @@ and previous snapshots are also available at http://buildroot.net/downloads/snapshots/.

-

To download Buildroot using Git you can simply follow +

To download Buildroot using Git, you can simply follow the rules described on the "Accessing Git" page (http://buildroot.net/git.html) of the Buildroot website @@ -166,7 +166,7 @@ the libncurses5-dev package is required to use the menuconfig interface, libqt3-mt-dev is required to use the xconfig interface, and libglib2.0-dev, libgtk2.0-dev - and libglade2-dev are needed to used the gconfig interface.

+ and libglade2-dev are needed to use the gconfig interface.

For each menu entry in the configuration tool, you can find associated help that describes the purpose of the entry.

@@ -218,10 +218,10 @@ libraries and applications for the target that depend on other libraries. -
  • target/ which contains almost the root - filesystem for the target: everything needed is present except the - device files in /dev/ (Buildroot can't create them - because Buildroot doesn't run as root and does not want to run as +
  • target/ which contains almost the complete + root filesystem for the target: everything needed is present except + the device files in /dev/ (Buildroot can't create them + because Buildroot doesn't run as root and doesn't want to run as root). Therefore, this directory should not be used on your target. Instead, you should use one of the images built in the images/ directory. If you need an extracted image of the @@ -229,10 +229,12 @@ generated in images/ and extract it as root.
    Compared to staging/, target/ contains only the files and libraries needed to run the selected target applications: - the development files (headers, etc.) are not present.
    • + the development files (headers, etc.) are not present, unless the + development files in target filesystem option is selected. +
  • host/ contains the installation of tools compiled for - the host that are needed for the proper execution of Buildroot except + the host that are needed for the proper execution of Buildroot, except for the cross-compilation toolchain which is installed under staging/.
    • @@ -287,13 +289,13 @@

    Environment variables

    -

    Buildroot also honors some environment variables when they are passed +

    Buildroot also honors some environment variables, when they are passed to make or set in the environment:

    • HOSTCXX, the host C++ compiler to use
    • HOSTCC, the host C compiler to use
    • UCLIBC_CONFIG_FILE=<path/to/.config>, path to - the uClibc configuration file to use to compile uClibc if an + the uClibc configuration file, used to compile uClibc, if an internal toolchain is being built
    • BUSYBOX_CONFIG_FILE=<path/to/.config>, path to the Busybox configuration file
      • @@ -305,14 +307,14 @@ in your $HOME:

      -$ make UCLIBC_CONFIG_FILE=uClibc.config BUSYBOX_CONFIG_FILE=$HOME/bb.config
+ $ make UCLIBC_CONFIG_FILE=uClibc.config BUSYBOX_CONFIG_FILE=$HOME/bb.config

      If you want to use a compiler other than the default gcc or g++ for building helper-binaries on your host, then do

      -$ make HOSTCXX=g++-4.3-HEAD HOSTCC=gcc-4.3-HEAD
+ $ make HOSTCXX=g++-4.3-HEAD HOSTCC=gcc-4.3-HEAD

      Customizing the generated target filesystem

      @@ -335,20 +337,20 @@ $ make HOSTCXX=g++-4.3-HEAD HOSTCC=gcc-4.3-HEAD can't do everything on this target filesystem skeleton, but changes to it do remain even if you completely rebuild the cross-compilation toolchain and the tools.
      You can also customize the - target/generic/device_table.txt file which is used by the + target/generic/device_table.txt file, which is used by the tools that generate the target filesystem image to properly set permissions and create device nodes.
      These customizations are deployed into output/target/ just before the actual image is made. Simply rebuilding the image by running make should propagate any new changes to the image. -
    • Add support for your own target in Buildroot so that you +
    • Add support for your own target in Buildroot, so that you have your own target skeleton (see this section for details).
    • In the Buildroot configuration, you can specify the path to a - post-build script that gets called after Buildroot builds all - the selected software but before the the rootfs packages are + post-build script, that gets called after Buildroot builds all + the selected software, but before the rootfs packages are assembled. The destination root filesystem folder is given as the first argument to this script, and this script can then be used to copy programs, static data or any other needed file to your target @@ -360,7 +362,7 @@ $ make HOSTCXX=g++-4.3-HEAD HOSTCC=gcc-4.3-HEAD
    • A special package, customize, stored in package/customize can be used. You can put all the files that you want to see in the final target root filesystem - in package/customize/source and then enable this + in package/customize/source, and then enable this special package in the configuration system.
    @@ -368,10 +370,10 @@ $ make HOSTCXX=g++-4.3-HEAD HOSTCC=gcc-4.3-HEAD

    Busybox is very configurable, and you may want to customize it. You can follow these simple steps to - do so. This method isn't optimal, but it's simple and it works:

    + do so. This method isn't optimal, but it's simple, and it works:

      -
    1. Do an initial compilation of Buildroot with busybox without +
    2. Do an initial compilation of Buildroot, with busybox, without trying to customize it.
    3. Invoke make busybox-menuconfig. @@ -382,8 +384,8 @@ $ make HOSTCXX=g++-4.3-HEAD HOSTCC=gcc-4.3-HEAD

    Otherwise, you can simply change the - package/busybox/busybox-<version>.config file if you - know the options you want to change without using the configuration tool. + package/busybox/busybox-<version>.config file, if you + know the options you want to change, without using the configuration tool.

    If you want to use an existing config file for busybox, then see @@ -391,8 +393,8 @@ $ make HOSTCXX=g++-4.3-HEAD HOSTCC=gcc-4.3-HEAD

    Customizing the uClibc configuration

    -

    Just like BusyBox, uClibc offers a lot of +

    Just like BusyBox, + uClibc offers a lot of configuration options. They allow you to select various functionalities depending on your needs and limitations.

    @@ -420,7 +422,7 @@ $ make HOSTCXX=g++-4.3-HEAD HOSTCC=gcc-4.3-HEAD

    Otherwise, you can simply change toolchain/uClibc/uClibc.config or - toolchain/uClibc/uClibc.config-locale without running + toolchain/uClibc/uClibc.config-locale, without running the configuration assistant.

    If you want to use an existing config file for uclibc, then see @@ -428,11 +430,12 @@ $ make HOSTCXX=g++-4.3-HEAD HOSTCC=gcc-4.3-HEAD

    Customizing the Linux kernel configuration

    -

    The Linux kernel configuration can be customized just like BusyBox and uClibc - using make linux26-menuconfig. Make sure you have - enabled the kernel build in make menuconfig first. - Once done, run make to (re)build everything.

    +

    The Linux kernel configuration can be customized just like + BusyBox and + uClibc using make linux26-menuconfig + . Make sure you have enabled the kernel build in make + menuconfig first. Once done, run make to (re)build + everything.

    If you want to use an existing config file for Linux, then see section environment variables.

    @@ -501,13 +504,13 @@ $(ZLIB_DIR)/libz.a: $(ZLIB_DIR)/.configured output/build/zlib-version/libz.a.

    Note that most packages, if not all, will progressively be - ported over the generic or the autotools infrastructure, making it + ported over to the generic or autotools infrastructure, making it much easier to rebuild individual packages.

    How Buildroot works

    As mentioned above, Buildroot is basically a set of Makefiles that - downloads, configures and compiles software with the correct options. It + download, configure, and compile software with the correct options. It also includes patches for various software packages — mainly the ones involved in the cross-compilation tool chain (gcc, binutils and uClibc).

    @@ -632,7 +635,7 @@ endif BOARD_PATH variable set to target/device/yourcompany/project-foobar as it will simplify further definitions. Then, the file might define - one or several of the following variables: + one or more of the following variables:
    • TARGET_SKELETON to a directory that contains the target skeleton for your project. If this variable is @@ -658,7 +661,7 @@ endif

      Using the generated toolchain outside Buildroot

      -

      You may want to compile for your target your own programs or other +

      You may want to compile, for your target, your own programs or other software that are not packaged in Buildroot. In order to do this you can use the toolchain that was generated by Buildroot.

      @@ -686,7 +689,7 @@ endif downloaded by the Makefiles are all stored in the DL_DIR which by default is the dl directory. It's useful, for example, if you want to keep a complete version of Buildroot which is - know to be working with the associated tarballs. This will allow you to + known to be working with the associated tarballs. This will allow you to regenerate the toolchain and the target filesystem with exactly the same versions.

      @@ -695,7 +698,7 @@ endif link from the dl directory to the shared download location:

      -ln -s <shared download location> dl
+ $ ln -s <shared download location> dl

      Another way of accessing a shared download location is to @@ -705,7 +708,7 @@ ln -s <shared download location> dl "~/.bashrc".

      -export BUILDROOT_DL_DIR <shared download location>
+ $ export BUILDROOT_DL_DIR <shared download location>

      Using an external toolchain

      @@ -718,7 +721,7 @@ export BUILDROOT_DL_DIR <shared download location> uClibc). Buildroot supports using an external toolchain.

      -

      To enable the use of an external toolchain, go in the +

      To enable the use of an external toolchain, go to the Toolchain menu, and :

        @@ -747,10 +750,10 @@ export BUILDROOT_DL_DIR <shared download location>

        Adding new packages to Buildroot

        -

        This section covers how new packages (userspace libraries or - applications) can be integrated into Buildroot. It also allows to - understand how existing packages are integrated, which is needed to fix - issues or tune their configuration.

        +

        This section covers how new packages (userspace libraries or + applications) can be integrated into Buildroot. It also shows how existing + packages are integrated, which is needed for fixing issues or tuning their + configuration.

        • Package directory
          • @@ -770,13 +773,12 @@ export BUILDROOT_DL_DIR <shared download location>

          Package directory

          First of all, create a directory under the package - directory for your software, for example foo.

          + directory for your software, for example libfoo.

          Some packages have been grouped by topic in a sub-directory: - multimedia, java, databases, - editors, x11r7, games. If your - package fits in one of these categories, then create your package - directory in these.

          + multimedia, java, x11r7, and + games. If your package fits in one of these + categories, then create your package directory in these.

          Config.in file

          @@ -816,35 +818,35 @@ source "package/libfoo/Config.in"

          The .mk file

          Finally, here's the hardest part. Create a file named - foo.mk. It describes how the package should be + libfoo.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:

            -
          • Makefiles for generic packages (not using autotools), based on an - infrastructure similar to the one used for autotools-based packages, - but which requires a little more work from the developer : specify - what should be done at for the configuration, compilation, installation - and cleanup of the package. This infrastructure must be used for all - packages that do not use the autotools as their build system. In the - future, other specialized infrastructures might be written for other - build systems.
            We cover them through a - tutorial and a +
          • Makefiles for generic packages (not using autotools): These + are based on an infrastructure similar to the one used for + autotools-based packages, but requires a little more work from the + developer. They specify what should be done for the configuration, + compilation, installation and cleanup of the package. This + infrastructure must be used for all packages that do not use the + autotools as their build system. In the future, other specialized + infrastructures might be written for other build systems.
            We cover + them through a tutorial and a reference.
            • -
          • Makefiles for autotools-based (autoconf, automake, etc.) software. - We provide a dedicated infrastructure for such packages, since - autotools is a very common build system. This infrastructure must +
          • Makefiles for autotools-based software (autoconf, automake, + etc.): We provide a dedicated infrastructure for such packages, since + autotools is a very common build system. This infrastructure must be used for new packages that rely on the autotools as their build system.
            We cover them through a tutorial and a reference.
            • -
          • Manual Makefiles. These are currently obsolete and no new manual - Makefiles should be added. However, since there are still many of them - in the tree and because the , we keep them documented in a +
          • Manual Makefiles: These are currently obsolete, and no new + manual Makefiles should be added. However, since there are still many + of them in the tree, we keep them documented in a tutorial.
          @@ -880,7 +882,7 @@ source "package/libfoo/Config.in" 27: $(eval $(call GENTARGETS,package,libfoo)) -

          The Makefile begins on line 6 to 8 by metadata informations: the +

          The Makefile begins on line 6 to 8 with metadata information: 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 @@ -890,7 +892,7 @@ source "package/libfoo/Config.in" 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 + 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.

          @@ -932,13 +934,13 @@ source "package/libfoo/Config.in"
        • The second argument is the lower-cased package name. It must match the prefix of the variables in the .mk file and must match the configuration option name in the Config.in - file. For example, if the package name is libfoo, so the - variables in the .mk must start with + file. For example, if the package name is libfoo, then the + variables in the .mk file must start with LIBFOO_ and the configuration option in the Config.in file must be BR2_PACKAGE_LIBFOO.
        • The third argument is optional. It can be used to tell if the - package if a target package (cross-compiled for the target) or a host + package is a target package (cross-compiled for the target) or a host package (natively compiled for the host). If unspecified, it is assumed that it is a target package. See below for details.
        @@ -958,7 +960,7 @@ $(eval $(call GENTARGETS,package,libfoo,host)) 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 + variables of other packages, if they depend on libfoo or host-libfoo.

        The call to the GENTARGETS macro must be at the @@ -975,14 +977,14 @@ $(eval $(call GENTARGETS,package,libfoo,host)) details.

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

        • LIBFOO_VERSION, mandatory, must contain the version of the package. Note that if HOST_LIBFOO_VERSION doesn't - exist, it is assumed to be the same as LIBFOO_VERSION. -
          Example: LIBFOO_VERSION=0.1.2
          • + exist, it is assumed to be the same as LIBFOO_VERSION.
          + Example: LIBFOO_VERSION = 0.1.2
        • LIBFOO_SOURCE may contain the name of the tarball of the package. If HOST_LIBFOO_SOURCE is not specified, it @@ -1006,7 +1008,7 @@ $(eval $(call GENTARGETS,package,libfoo,host)) specified, then the location is assumed to be http://$$(BR2_SOURCEFORGE_MIRROR).dl.sourceforge.net/sourceforge/packagename.
          Example: - LIBFOO_SITE=http://www.foosoftware.org/libfoo.
          • + LIBFOO_SITE=http://www.libfoosoftware.org/libfoo.
        • LIBFOO_DEPENDENCIES lists the dependencies (in terms of package name) that are required for the current target package to @@ -1029,7 +1031,7 @@ $(eval $(call GENTARGETS,package,libfoo,host)) syntax:

          -LIBFOO_VERSION=2.32
+LIBFOO_VERSION = 2.32

          Now, the variables that define what should be performed at the @@ -1053,9 +1055,11 @@ LIBFOO_VERSION=2.32 to be performed to install the package to the target directory, when the package is a target package. The package must install its files to the directory given by $(TARGET_DIR). Only the files - required for execution of the package - should be installed. Header files and documentation should not be - installed.

          • + required for documentation and execution of the package + should be installed. Header files should not be installed, they will + be copied to the target, if the + development files in target filesystem option is selected. +
        • LIBFOO_INSTALL_STAGING_CMDS, used to list the actions to be performed to install the package to the staging directory, when @@ -1104,12 +1108,16 @@ endef

        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.

        + hooks. These define further actions to perform after existing steps. + Most 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. + However, since they are provided by the generic infrastructure, they are + documented here. The exception is LIBFOO_POST_PATCH_HOOKS. + Patching the package is not user definable, so + LIBFOO_POST_PATCH_HOOKS will be userful for generic packages. +

        The following hook points are available:

        @@ -1122,7 +1130,7 @@ endef
      • LIBFOO_POST_INSTALL_TARGET_HOOKS (for target packages only)
      -

      This variables are lists of variable names containing actions +

      These 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:

      @@ -1205,7 +1213,7 @@ LIBFOO_POST_PATCH_HOOKS += LIBFOO_POST_PATCH_FIXUP works by defining a number of variables before calling the AUTOTARGETS macro.

      -

      First, all the package meta-information variables that exist in the +

      First, all the package metadata information variables that exist in the generic infrastructure also exist in the autotools infrastructure: LIBFOO_VERSION, LIBFOO_SOURCE, LIBFOO_PATCH, LIBFOO_SITE, @@ -1230,11 +1238,11 @@ LIBFOO_POST_PATCH_HOOKS += LIBFOO_POST_PATCH_FIXUP options to pass to the configure script. By default, empty.

    • LIBFOO_MAKE, to specify an alternate make - command. This is typically useful when parallel make it enabled in + command. This is typically useful when parallel make is enabled in the configuration (using BR2_JLEVEL) but that this feature should be disabled for the given package, for one reason or another. By default, set to $(MAKE). If parallel building - is not supported by the package, then it should do + is not supported by the package, then it should be set to LIBFOO_MAKE=$(MAKE1).
    • LIBFOO_MAKE_ENV, to specify additional environment @@ -1261,11 +1269,11 @@ LIBFOO_POST_PATCH_HOOKS += LIBFOO_POST_PATCH_FIXUP default, the value is YES
    • LIBFOO_USE_CONFIG_CACHE tells whether the configure - script should really on a cache file that caches test results from - previous configure script. Usually, this variable should be left to - its default value. Only for specific packages having issues with the - configure cache can set this variable to the NO value - (but this is more a work-around than a really fix)
      • + script should use the central configure cache, which caches test + results from previous configure scripts. Usually, this variable should + be left to its default value. Only packages having issues with the + configure cache, can set this variable to the NO value + (but this is more of a work-around than a fix)
    • LIBFOO_INSTALL_STAGING_OPT contains the make options used to install the package to the staging directory. By default, the @@ -1275,12 +1283,9 @@ LIBFOO_POST_PATCH_HOOKS += LIBFOO_POST_PATCH_FIXUP
    • LIBFOO_INSTALL_TARGET_OPT contains the make options used to install the package to the target directory. By default, the - value is DESTDIR=$$(TARGET_DIR) install-strip if - BR2_ENABLE_DEBUG is not set, and - DESTDIR=$$(TARGET_DIR) install-exec if - BR2_ENABLE_DEBUG is set. These default values are correct - for most autotools packages, but it is still possible to override them - if needed.
      • + value is DESTDIR=$$(TARGET_DIR) install. The default + value is correct for most autotools packages, but it is still possible + to override it if needed.
    • LIBFOO_CLEAN_OPT contains the make options used to clean the package. By default, the value is clean.
      • @@ -1297,7 +1302,7 @@ LIBFOO_POST_PATCH_HOOKS += LIBFOO_POST_PATCH_FIXUP

      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:

      + still possible to customize what is done in any particular step:

      • By adding a post-operation hook (after extract, patch, configure, @@ -1305,7 +1310,7 @@ LIBFOO_POST_PATCH_HOOKS += LIBFOO_POST_PATCH_FIXUP infrastructure for details.
      • By overriding one of the steps. For example, even if the autotools - infrastructure is used, if the package .mk defines its + infrastructure is used, if the package .mk file defines its own LIBFOO_CONFIGURE_CMDS variable, it will be used instead of the default autotools one. However, using this method should be restricted to very specific cases. Do not use it in the @@ -1317,7 +1322,7 @@ LIBFOO_POST_PATCH_HOOKS += LIBFOO_POST_PATCH_FIXUP

        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 + kept to document the existing manual makefiles and to help understand how they work.

        @@ -1419,11 +1424,11 @@ LIBFOO_POST_PATCH_HOOKS += LIBFOO_POST_PATCH_FIXUP
 
     
        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, 
+    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.
        
 
@@ -1435,7 +1440,7 @@ LIBFOO_POST_PATCH_HOOKS += LIBFOO_POST_PATCH_FIXUP
     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 
+    /usr on your host system, but because the software will be 
     installed in  /usr on the target filesystem. Finally it 
     creates a .configured file to mark the software as 
     configured.
        
@@ -1458,7 +1463,7 @@ LIBFOO_POST_PATCH_HOOKS += LIBFOO_POST_PATCH_FIXUP
     to save space. 
        
 
     
        Line 40 defines the main target of the 
-    software — the one that will be eventually be used by the top level 
+    software — the one that will 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 
@@ -1468,13 +1473,13 @@ LIBFOO_POST_PATCH_HOOKS += LIBFOO_POST_PATCH_FIXUP
     
        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 
+    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 
+    support users that wish to do offline-builds. Furthermore, it eases 
     checking if all package-sources are downloadable.
        
 
     
        Lines 44-46 define a simple target to clean 
-    the software build by calling the Makefiles with the appropriate option. 
+    the software build by calling the Makefile with the appropriate options. 
     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).
        
@@ -1485,7 +1490,7 @@ LIBFOO_POST_PATCH_HOOKS += LIBFOO_POST_PATCH_FIXUP
     completely rm $(BUILD_DIR)/ package-version.
        
 
     
        Lines 51-58 add the target libfoo 
-    to the list of targets to be compiled by Buildroot by first checking if 
+    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.  
@@ -1497,14 +1502,14 @@ LIBFOO_POST_PATCH_HOOKS += LIBFOO_POST_PATCH_FIXUP
     
        Gettext integration and interaction with packages
        
 
     
        Many packages that support internationalization use the gettext 
-    library. Dependency on this library are fairly complicated and therefore 
-    deserves a few explanations.
        
+    library. Dependencies for this library are fairly complicated and therefore, 
+    deserves some explanation.
        
 
     
        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.
        
+    compiled, because it creates various kinds of build failures.
        
 
     
        Additionally, some packages (such as libglib2) do require gettext 
     unconditionally, while other packages (those who support 
@@ -1525,7 +1530,7 @@ LIBFOO_POST_PATCH_HOOKS += LIBFOO_POST_PATCH_FIXUP
 
     
          
       
        1. Use select BR2_PACKAGE_GETTEXT if BR2_NEEDS_GETTEXT 
-      and possibly select BR2_PACKAGE_LIBINTL if BR2_NEEDS_GETTEXT 
+      and possibly select BR2_PACKAGE_LIBINTL if BR2_NEEDS_GETTEXT, 
       if libintl is also needed
          2. 
 
       
        2. Use $(if $(BR2_NEEDS_GETTEXT),gettext) in the package 
@@ -1539,7 +1544,7 @@ LIBFOO_POST_PATCH_HOOKS += LIBFOO_POST_PATCH_FIXUP
       
        3. Use 
       select BR2_PACKAGE_GETTEXT if BR2_NEEDS_GETTEXT_IF_LOCALE 
       and possibly 
-      select BR2_PACKAGE_LIBINTL if BR2_NEEDS_GETTEXT_IF_LOCALE 
+      select BR2_PACKAGE_LIBINTL if BR2_NEEDS_GETTEXT_IF_LOCALE, 
       if libintl is also needed
          4. 
 
       
        4. Use $(if $(BR2_NEEDS_GETTEXT_IF_LOCALE),gettext) in 
-- 
2.30.2