NetCube-Systems-Austria/kumquat-buildroot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix buildroot.html typos

Browse Source 
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
This commit is contained in:
Yegor Yefremov 2010-09-28 14:28:55 +02:00 committed by Peter Korsgaard
parent 3e5e39a8a2
commit 3f1d79d379
1 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
docs/buildroot.html
View File

@ -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