From c09dda8e56bcae694e9e06fd1056df5ad5a53cdd Mon Sep 17 00:00:00 2001 From: Jerzy Grzegorek Date: Fri, 28 Mar 2014 22:24:50 +0100 Subject: [PATCH] manual: fix typo in abbreviation 'i.e.' Signed-off-by: Jerzy Grzegorek Signed-off-by: Thomas Petazzoni --- docs/manual/adding-packages-autotools.txt | 2 +- docs/manual/configure.txt | 12 ++++++------ docs/manual/customize-outside-br.txt | 2 +- docs/manual/faq-troubleshooting.txt | 2 +- 4 files changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/manual/adding-packages-autotools.txt b/docs/manual/adding-packages-autotools.txt index d0c92ffdb..cc668b526 100644 --- a/docs/manual/adding-packages-autotools.txt +++ b/docs/manual/adding-packages-autotools.txt @@ -119,7 +119,7 @@ cases, typical packages will therefore only use a few of them. +make+ command. By default, empty. * +LIBFOO_AUTORECONF+, tells whether the package should - be autoreconfigured or not (i.e, if the configure script and + be autoreconfigured or not (i.e. if the configure script and Makefile.in files should be re-generated by re-running autoconf, automake, libtool, etc.). Valid values are +YES+ and +NO+. By default, the value is +NO+ diff --git a/docs/manual/configure.txt b/docs/manual/configure.txt index 9681de00c..c1c9477a2 100644 --- a/docs/manual/configure.txt +++ b/docs/manual/configure.txt @@ -82,7 +82,7 @@ most important ones allow to: built. This library provides the interface between userspace applications and the Linux kernel. In order to know how to "talk" to the Linux kernel, the C library needs to have access to the - _Linux kernel headers_ (i.e, the +.h+ files from the kernel), which + _Linux kernel headers_ (i.e. the +.h+ files from the kernel), which define the interface between userspace and the kernel (system calls, data structures, etc.). Since this interface is backward compatible, the version of the Linux kernel headers used to build @@ -97,7 +97,7 @@ most important ones allow to: * Change the version of the GCC compiler, binutils and the C library. * Select a number of toolchain options (uClibc only): whether the - toolchain should have largefile support (i.e support for files + toolchain should have largefile support (i.e. support for files larger than 2 GB on 32 bits systems), IPv6 support, RPC support (used mainly for NFS), wide-char support, locale support (for internationalization), C\++ support or thread support. Depending on @@ -180,17 +180,17 @@ Buildroot itself. In general, all toolchains that support the developers. We do not support toolchains or SDK generated by OpenEmbedded or -Yocto, because these toolchains are not pure toolchains (i.e just the +Yocto, because these toolchains are not pure toolchains (i.e. just the compiler, binutils, the C and C++ libraries). Instead these toolchains come with a very large set of pre-compiled libraries and programs. Therefore, Buildroot cannot import the 'sysroot' of the toolchain, as it would contain hundreds of megabytes of pre-compiled libraries that are normally built by Buildroot. -We also do not support using the distribution toolchain (i.e the +We also do not support using the distribution toolchain (i.e. the gcc/binutils/C library installed by your distribution) as the toolchain to build software for the target. This is because your -distribution toolchain is not a "pure" toolchain (i.e only with the +distribution toolchain is not a "pure" toolchain (i.e. only with the C/C++ library), so we cannot import it properly into the Buildroot build environment. So even if you are building a system for a x86 or x86_64 target, you have to generate a cross-compilation toolchain with @@ -235,7 +235,7 @@ different solutions to handle the +/dev+ directory : * The first solution is *Static using device table*. This is the old classical way of handling device files in Linux. With this method, the device files are persistently stored in the root filesystem - (i.e they persist accross reboots), and there is nothing that will + (i.e. they persist accross reboots), and there is nothing that will automatically create and remove those device files when hardware devices are added or removed from the system. Buildroot therefore creates a standard set of device files using a _device table_, the diff --git a/docs/manual/customize-outside-br.txt b/docs/manual/customize-outside-br.txt index 749894094..6ee55a358 100644 --- a/docs/manual/customize-outside-br.txt +++ b/docs/manual/customize-outside-br.txt @@ -78,7 +78,7 @@ Or disable the usage of external definitions: directories called +board//+ under +BR2_EXTERNAL+. This matches the directory structure used within Buildroot. - * One can store package recipes (i.e +Config.in+ and + * One can store package recipes (i.e. +Config.in+ and +.mk+), or even custom configuration options and make logic. Buildroot automatically includes +BR2_EXTERNAL/Config.in+ to make it appear in the top-level configuration menu, and includes diff --git a/docs/manual/faq-troubleshooting.txt b/docs/manual/faq-troubleshooting.txt index a5079e341..473b0e283 100644 --- a/docs/manual/faq-troubleshooting.txt +++ b/docs/manual/faq-troubleshooting.txt @@ -138,7 +138,7 @@ is much more complicated than that: * When a package is unselected from the configuration, it is not sufficient to remove just the files it installed. One must also - remove all its reverse dependencies (i.e packages relying on it) + remove all its reverse dependencies (i.e. packages relying on it) and rebuild all those packages. For example, package A depends optionally on the OpenSSL library. Both are selected, and Buildroot is built. Package A is built with crypto support using OpenSSL.