ref-manual, dev-manual: Clarifying "native" and "sdknative"
Fixes [YOCTO #8620] I applied some review comments for the changes made to several areas in both these manuals. Minor wording fixes and the dropping of some changes as directed by Joshua Lock. (From yocto-docs rev: 71af89da612c37162ba27844c297879d643caf65) Signed-off-by: Scott Rifenbark <srifenbark@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Scott Rifenbark
Richard Purdie
parent
a1970eb17b
commit
3b410498fe
|
|
@ -3603,11 +3603,10 @@
|
|||
<title>Additional Implementation Details</title>
|
||||
|
||||
<para>
|
||||
Different packaging systems have different levels of
|
||||
native Multilib support (i.e. support for the host build
|
||||
machine).
|
||||
For the RPM Package Management System, the following
|
||||
implementation details exist:
|
||||
Different packaging systems have different levels of native Multilib
|
||||
support.
|
||||
For the RPM Package Management System, the following implementation details
|
||||
exist:
|
||||
<itemizedlist>
|
||||
<listitem><para>A unique architecture is defined for the Multilib packages,
|
||||
along with creating a unique deploy folder under
|
||||
|
|
@ -6377,9 +6376,8 @@
|
|||
developers when building for multiple machines.
|
||||
When you use the same <filename>TMPDIR</filename> for
|
||||
multiple machine builds, the OpenEmbedded build system can
|
||||
reuse the existing native (i.e. host system) and often
|
||||
cross-recipes (i.e. <filename>nativesdk</filename>
|
||||
for multiple machines.
|
||||
reuse the existing native and often cross-recipes for
|
||||
multiple machines.
|
||||
Thus, build time decreases.
|
||||
<note>
|
||||
If
|
||||
|
|
@ -7582,14 +7580,16 @@
|
|||
Consequently, you usually need to add a
|
||||
cross-compilation function to the package.
|
||||
</para>
|
||||
|
||||
<para>Many packages based on Automake compile and
|
||||
run the test suite by using a single command
|
||||
such as <filename>make check</filename>.
|
||||
However, the native <filename>make check</filename>
|
||||
that runs on the host system
|
||||
However, the host <filename>make check</filename>
|
||||
builds and runs on the same computer, while
|
||||
cross-compiling requires that the package is built
|
||||
on the host but executed on the target.
|
||||
on the host but executed for the target
|
||||
architecture (though often, as in the case for
|
||||
ptest, the execution occurs on the host).
|
||||
The built version of Automake that ships with the
|
||||
Yocto Project includes a patch that separates
|
||||
building and execution.
|
||||
|
|
|
|||
|
|
@ -450,9 +450,7 @@
|
|||
$ sh poky-glibc-x86_64-buildtools-tarball-x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh
|
||||
</literallayout>
|
||||
During execution, a prompt appears that allows you to
|
||||
choose the installation directory for these tools
|
||||
designed to run on the target machine
|
||||
(<link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>).
|
||||
choose the installation directory.
|
||||
For example, you could choose the following:
|
||||
<literallayout class='monospaced'>
|
||||
/home/<replaceable>your-username</replaceable>/buildtools
|
||||
|
|
@ -532,8 +530,7 @@
|
|||
<listitem><para>
|
||||
On the machine that does not meet the requirements,
|
||||
run the <filename>.sh</filename> file
|
||||
to install the tools built to run on the target machine
|
||||
(<link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>).
|
||||
to install the tools.
|
||||
Here is an example:
|
||||
<literallayout class='monospaced'>
|
||||
$ sh poky-glibc-x86_64-buildtools-tarball-x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh
|
||||
|
|
|
|||
|
|
@ -193,9 +193,10 @@
|
|||
as a prefix, which simplifies a lot of the packaging code for
|
||||
<filename>nativesdk</filename> recipes.
|
||||
All custom <filename>nativesdk</filename> recipes, which are
|
||||
recipes built on the host system to create packages for the
|
||||
target machine, and any
|
||||
references need to be updated to use
|
||||
relocatable packages for the native architecture as specified
|
||||
in
|
||||
<link linkend='var-SDK_ARCH'><filename>SDK_ARCH</filename></link>,
|
||||
and any references need to be updated to use
|
||||
<filename>nativesdk-*</filename> instead of
|
||||
<filename>*-nativesdk</filename>.
|
||||
</para>
|
||||
|
|
|
|||
|
|
@ -463,11 +463,10 @@
|
|||
|
||||
<para>
|
||||
The <filename>chrpath</filename> class
|
||||
is a wrapper around the "chrpath" utility.
|
||||
This utility is used during the build process for
|
||||
<filename>nativesdk</filename>, <filename>cross</filename>, and
|
||||
<filename>cross-canadian</filename> recipes, which run on the host
|
||||
system to create packages for the target hardware and change
|
||||
is a wrapper around the "chrpath" utility, which is used during the
|
||||
build process for <filename>nativesdk</filename>,
|
||||
<filename>cross</filename>, and
|
||||
<filename>cross-canadian</filename> recipes to change
|
||||
<filename>RPATH</filename> records within binaries in order to make
|
||||
them relocatable.
|
||||
</para>
|
||||
|
|
|
|||
|
|
@ -477,7 +477,12 @@
|
|||
It does not matter if the work directory changes because it should
|
||||
not affect the output for target packages.
|
||||
Also, the build process has the objective of making native
|
||||
(build host) or cross packages (target hardware) relocatable.
|
||||
or cross packages relocatable.
|
||||
<note>
|
||||
Both native and cross packages run on the build host.
|
||||
However, cross packages generate output for the target
|
||||
architecture.
|
||||
</note>
|
||||
The checksum therefore needs to exclude
|
||||
<filename>WORKDIR</filename>.
|
||||
The simplistic approach for excluding the work directory is to set
|
||||
|
|
|
|||
Loading…
Reference in New Issue