|
|
@@ -171,7 +171,7 @@ or
|
|
|
|
|
|
<p>All of these "make" commands will need to build a configuration
|
|
|
utility, so you may need to install "development" packages for
|
|
|
- relevent libraries used by the configuration utilities.
|
|
|
+ relevant libraries used by the configuration utilities.
|
|
|
On Debian-like systems, the
|
|
|
<code>libncurses5-dev</code> package is required to use the
|
|
|
<i>menuconfig</i> interface, <code>libqt3-mt-dev</code> is
|
|
|
@@ -345,7 +345,7 @@ $ make HOSTCXX=g++-4.3-HEAD HOSTCC=gcc-4.3-HEAD
|
|
|
toolchain and tools, these changes will be lost. </li>
|
|
|
|
|
|
<li>Customize the target filesystem skeleton available under
|
|
|
- <code>target/generic/target_skeleton/</code>. You can customize
|
|
|
+ <code>fs/skeleton/</code>. You can customize
|
|
|
configuration files or other stuff here. However, the full file hierarchy
|
|
|
is not yet present because it's created during the compilation process.
|
|
|
Therefore, you can't do everything on this target filesystem skeleton, but
|
|
|
@@ -486,12 +486,12 @@ $ make HOSTCXX=g++-4.3-HEAD HOSTCC=gcc-4.3-HEAD
|
|
|
and which steps remain to be done, Buildroot maintains stamp
|
|
|
files (empty files that just tell whether this or that action
|
|
|
has been done). The problem is that these stamp files are not
|
|
|
- uniformely named and handled by the different packages, so some
|
|
|
+ uniformly named and handled by the different packages, so some
|
|
|
understanding of the particular package is needed.</p>
|
|
|
|
|
|
<p>For packages relying on Buildroot packages infrastructures (see
|
|
|
<a href="#add_packages">this section</a> for details), the
|
|
|
- following stamp files are relevent:</p>
|
|
|
+ following stamp files are relevant:</p>
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
@@ -704,7 +704,7 @@ endif
|
|
|
<p>The toolchain generated by Buildroot is located by default in
|
|
|
<code>output/staging/</code>. The simplest way to use it
|
|
|
is to add <code>output/staging/usr/bin/</code> to your PATH
|
|
|
- environnement variable and then to use
|
|
|
+ environment variable and then to use
|
|
|
<code>ARCH-linux-gcc</code>, <code>ARCH-linux-objdump</code>,
|
|
|
<code>ARCH-linux-ld</code>, etc. </p>
|
|
|
|
|
|
@@ -885,7 +885,7 @@ source "package/libfoo/Config.in"
|
|
|
href="#generic-reference">reference</a>.</li>
|
|
|
|
|
|
<li>Makefiles for autotools-based (autoconf, automake, etc.)
|
|
|
- softwares. We provide a dedicated infrastructure for such
|
|
|
+ software. We provide a dedicated infrastructure for such
|
|
|
packages, since autotools is a very common build system. This
|
|
|
infrastructure <i>must</i> be used for new packages that rely on
|
|
|
the autotools as their build system.<br/>We cover them through a
|
|
|
@@ -1614,8 +1614,8 @@ LIBFOO_POST_PATCH_HOOKS += LIBFOO_POST_PATCH_FIXUP
|
|
|
gettext library should not be compiled, because it creates various
|
|
|
kind of build failures.</p>
|
|
|
|
|
|
- <p>Additionnaly, some packages (such as libglib2) do require
|
|
|
- gettext unconditionnally, while other packages (those who
|
|
|
+ <p>Additionally, some packages (such as libglib2) do require
|
|
|
+ gettext unconditionally, while other packages (those who
|
|
|
support <code>--disable-nls</code> in general) only require
|
|
|
gettext when locale support is enabled.</p>
|
|
|
|
|
|
@@ -1631,7 +1631,7 @@ LIBFOO_POST_PATCH_HOOKS += LIBFOO_POST_PATCH_FIXUP
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
- <p>Therefore, packages that unconditionnally need gettext should:</p>
|
|
|
+ <p>Therefore, packages that unconditionally need gettext should:</p>
|
|
|
|
|
|
<ol>
|
|
|
<li>Use <code>select BR2_PACKAGE_GETTEXT if
|
Yegor Yefremov