sysmo-bts
/
generic-poky
9
0
Fork 0
Code Pull Requests Releases Activity

ref-manual, dev-manual: Clarification of "native" and "sdknative" 

Fixes [YOCTO #8620]

I went through and made some judgement calls on the use of
"native" and "sdknative".  I tried to make sure that the reader
understood the real meaning of these terms.

(From yocto-docs rev: d711e8c6dfb32a4ad79e9d11dbf44fbc759d0245)

Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Scott Rifenbark 2016-02-16 15:42:55 -08:00 committed by Richard Purdie
parent 952bcc7fd5
commit c5b4f69821
8 changed files with 98 additions and 71 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
documentation/dev-manual/dev-manual-common-tasks.xml
View File

@ -3603,10 +3603,11 @@
<title>Additional Implementation Details</title> <title>Additional Implementation Details</title>
<para> <para>
Different packaging systems have different levels of native Multilib Different packaging systems have different levels of
support. native Multilib support (i.e. support for the host build
For the RPM Package Management System, the following implementation details machine).
exist: For the RPM Package Management System, the following
implementation details exist:
<itemizedlist> <itemizedlist>
<listitem><para>A unique architecture is defined for the Multilib packages, <listitem><para>A unique architecture is defined for the Multilib packages,
along with creating a unique deploy folder under along with creating a unique deploy folder under
@ -3823,7 +3824,8 @@
in the form generated by the build system. in the form generated by the build system.
</para></listitem> </para></listitem>
<listitem><para> <listitem><para>
You must build several native tools: You must build several native tools, which are tools
built to run on the build system:
<literallayout class='monospaced'> <literallayout class='monospaced'>
$ bitbake parted-native dosfstools-native mtools-native $ bitbake parted-native dosfstools-native mtools-native
</literallayout> </literallayout>
@ -6375,8 +6377,9 @@
developers when building for multiple machines. developers when building for multiple machines.
When you use the same <filename>TMPDIR</filename> for When you use the same <filename>TMPDIR</filename> for
multiple machine builds, the OpenEmbedded build system can multiple machine builds, the OpenEmbedded build system can
reuse the existing native and often cross-recipes for reuse the existing native (i.e. host system) and often
multiple machines. cross-recipes (i.e. <filename>nativesdk</filename>
for multiple machines.
Thus, build time decreases. Thus, build time decreases.
<note> <note>
If If
@ -7583,6 +7586,7 @@
run the test suite by using a single command run the test suite by using a single command
such as <filename>make check</filename>. such as <filename>make check</filename>.
However, the native <filename>make check</filename> However, the native <filename>make check</filename>
that runs on the host system
builds and runs on the same computer, while builds and runs on the same computer, while
cross-compiling requires that the package is built cross-compiling requires that the package is built
on the host but executed on the target. on the host but executed on the target.
@ -8169,7 +8173,8 @@
specific to or dependent on the target specific to or dependent on the target
architecture:</emphasis> architecture:</emphasis>
You can work around these attempts by using native You can work around these attempts by using native
tools to accomplish the same tasks, or tools, which run on the host system,
to accomplish the same tasks, or
by alternatively running the processes under QEMU, by alternatively running the processes under QEMU,
which has the <filename>qemu_run_binary</filename> which has the <filename>qemu_run_binary</filename>
function. function.

19
documentation/dev-manual/dev-manual-start.xml
View File

@ -341,14 +341,17 @@
</para> </para>
<para> <para>
Using a pre-built binary is ideal for developing software applications to run on your Using a pre-built binary is ideal for developing software
target hardware. applications to run on your target hardware.
To do this, you need to be able to access the appropriate cross-toolchain tarball for To do this, you need to be able to access the appropriate
the architecture on which you are developing. cross-toolchain tarball for the architecture on which you are
If you are using an SDK type image, the image ships with the complete toolchain native to developing.
the architecture. If you are using an SDK type image, the image ships with the complete
If you are not using an SDK type image, you need to separately download and toolchain native to the architecture (i.e. a toolchain designed to
install the stand-alone Yocto Project cross-toolchain tarball. run on the
<ulink url='&YOCTO_DOCS_REF_URL;#var-SDKMACHINE'><filename>SDKMACHINE</filename></ulink>).
If you are not using an SDK type image, you need to separately download
and install the stand-alone Yocto Project cross-toolchain tarball.
</para> </para>
<para> <para>

2
documentation/ref-manual/faq.xml
View File

@ -791,7 +791,7 @@
<qandaentry> <qandaentry>
<question> <question>
<para> <para>
The files provided by my <filename>-native</filename> recipe do The files provided by my <filename>*-native</filename> recipe do
not appear to be available to other recipes. not appear to be available to other recipes.
Files are missing from the native sysroot, my recipe is Files are missing from the native sysroot, my recipe is
installing to the wrong place, or I am getting permissions installing to the wrong place, or I am getting permissions

7
documentation/ref-manual/introduction.xml
View File

@ -450,7 +450,9 @@
$ sh poky-glibc-x86_64-buildtools-tarball-x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh $ sh poky-glibc-x86_64-buildtools-tarball-x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh
</literallayout> </literallayout>
During execution, a prompt appears that allows you to During execution, a prompt appears that allows you to
choose the installation directory. choose the installation directory for these tools
designed to run on the target machine
(<link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>).
For example, you could choose the following: For example, you could choose the following:
<literallayout class='monospaced'> <literallayout class='monospaced'>
/home/<replaceable>your-username</replaceable>/buildtools /home/<replaceable>your-username</replaceable>/buildtools
@ -530,7 +532,8 @@
<listitem><para> <listitem><para>
On the machine that does not meet the requirements, On the machine that does not meet the requirements,
run the <filename>.sh</filename> file run the <filename>.sh</filename> file
to install the tools. to install the tools built to run on the target machine
(<link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>).
Here is an example: Here is an example:
<literallayout class='monospaced'> <literallayout class='monospaced'>
$ sh poky-glibc-x86_64-buildtools-tarball-x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh $ sh poky-glibc-x86_64-buildtools-tarball-x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh

17
documentation/ref-manual/migration.xml
View File

@ -97,13 +97,14 @@
<para> <para>
The shared state cache (sstate-cache), as pointed to by The shared state cache (sstate-cache), as pointed to by
<link linkend='var-SSTATE_DIR'><filename>SSTATE_DIR</filename></link>, by default <link linkend='var-SSTATE_DIR'><filename>SSTATE_DIR</filename></link>,
now has two-character subdirectories to prevent issues arising by default now has two-character subdirectories to prevent
from too many files in the same directory. issues arising from too many files in the same directory.
Also, native sstate-cache packages will go into a subdirectory named using Also, native sstate-cache packages, which are built to run
on the host system, will go into a subdirectory named using
the distro ID string. the distro ID string.
If you copy the newly structured sstate-cache to a mirror location If you copy the newly structured sstate-cache to a mirror
(either local or remote) and then point to it in location (either local or remote) and then point to it in
<link linkend='var-SSTATE_MIRRORS'><filename>SSTATE_MIRRORS</filename></link>, <link linkend='var-SSTATE_MIRRORS'><filename>SSTATE_MIRRORS</filename></link>,
you need to append "PATH" to the end of the mirror URL so that you need to append "PATH" to the end of the mirror URL so that
the path used by BitBake before the mirror substitution is the path used by BitBake before the mirror substitution is
@ -191,7 +192,9 @@
The suffix <filename>nativesdk</filename> is now implemented The suffix <filename>nativesdk</filename> is now implemented
as a prefix, which simplifies a lot of the packaging code for as a prefix, which simplifies a lot of the packaging code for
<filename>nativesdk</filename> recipes. <filename>nativesdk</filename> recipes.
All custom <filename>nativesdk</filename> recipes and any 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 references need to be updated to use
<filename>nativesdk-*</filename> instead of <filename>nativesdk-*</filename> instead of
<filename>*-nativesdk</filename>. <filename>*-nativesdk</filename>.

13
documentation/ref-manual/ref-classes.xml
View File

@ -463,10 +463,11 @@
<para> <para>
The <filename>chrpath</filename> class The <filename>chrpath</filename> class
is a wrapper around the "chrpath" utility, which is used during the is a wrapper around the "chrpath" utility.
build process for <filename>nativesdk</filename>, This utility is used during the build process for
<filename>cross</filename>, and <filename>nativesdk</filename>, <filename>cross</filename>, and
<filename>cross-canadian</filename> recipes to change <filename>cross-canadian</filename> recipes, which run on the host
system to create packages for the target hardware and change
<filename>RPATH</filename> records within binaries in order to make <filename>RPATH</filename> records within binaries in order to make
them relocatable. them relocatable.
</para> </para>
@ -1146,8 +1147,8 @@
<title><filename>gzipnative.bbclass</filename></title> <title><filename>gzipnative.bbclass</filename></title>
<para> <para>
The <filename>gzipnative</filename> The <filename>gzipnative</filename> class enables the use of
class enables the use of native versions of <filename>gzip</filename> different native versions of <filename>gzip</filename>
and <filename>pigz</filename> rather than the versions of these tools and <filename>pigz</filename> rather than the versions of these tools
from the build host. from the build host.
</para> </para>

72
documentation/ref-manual/ref-variables.xml
View File

@ -1396,15 +1396,22 @@
<para role="glossdeffirst"> <para role="glossdeffirst">
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> <!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
The bare name of the recipe. The bare name of the recipe.
This variable is a version of the <link linkend='var-PN'><filename>PN</filename></link> variable This variable is a version of the
but removes common suffixes such as "-native" and "-cross" as well <link linkend='var-PN'><filename>PN</filename></link>
as removes common prefixes such as multilib's "lib64-" and "lib32-". variable but removes common suffixes such as
<filename>-native</filename> and
<filename>-cross</filename> as well
as removes common prefixes such as multilib's
<filename>lib64-</filename> and
<filename>lib32-</filename>.
The exact list of suffixes removed is specified by the The exact list of suffixes removed is specified by the
<link linkend='var-SPECIAL_PKGSUFFIX'><filename>SPECIAL_PKGSUFFIX</filename></link> variable. <link linkend='var-SPECIAL_PKGSUFFIX'><filename>SPECIAL_PKGSUFFIX</filename></link>
variable.
The exact list of prefixes removed is specified by the The exact list of prefixes removed is specified by the
<link linkend='var-MLPREFIX'><filename>MLPREFIX</filename></link> variable. <link linkend='var-MLPREFIX'><filename>MLPREFIX</filename></link>
variable.
Prefixes are removed for <filename>multilib</filename> Prefixes are removed for <filename>multilib</filename>
and <filename>nativesdk</filename> cases. and <filename>nativesdk-</filename> cases.
</para> </para>
</glossdef> </glossdef>
</glossentry> </glossentry>
@ -1467,7 +1474,7 @@
Specifies the flags to pass to the C pre-processor Specifies the flags to pass to the C pre-processor
(i.e. to both the C and the C++ compilers) when building (i.e. to both the C and the C++ compilers) when building
for the build host. for the build host.
When building in the <filename>native</filename> context, When building in the <filename>-native</filename> context,
<link linkend='var-CPPFLAGS'><filename>CPPFLAGS</filename></link> <link linkend='var-CPPFLAGS'><filename>CPPFLAGS</filename></link>
is set to the value of this variable by default. is set to the value of this variable by default.
</para> </para>
@ -1483,7 +1490,7 @@
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> <!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
Specifies the flags to pass to the C++ compiler when Specifies the flags to pass to the C++ compiler when
building for the build host. building for the build host.
When building in the <filename>native</filename> context, When building in the <filename>-native</filename> context,
<link linkend='var-CXXFLAGS'><filename>CXXFLAGS</filename></link> <link linkend='var-CXXFLAGS'><filename>CXXFLAGS</filename></link>
is set to the value of this variable by default. is set to the value of this variable by default.
</para> </para>
@ -1558,7 +1565,7 @@
The OpenEmbedded build system uses the The OpenEmbedded build system uses the
<filename>BUILD_PREFIX</filename> value to set the <filename>BUILD_PREFIX</filename> value to set the
<link linkend='var-TARGET_PREFIX'><filename>TARGET_PREFIX</filename></link> <link linkend='var-TARGET_PREFIX'><filename>TARGET_PREFIX</filename></link>
when building for native recipes. when building for <filename>native</filename> recipes.
</para> </para>
</glossdef> </glossdef>
</glossentry> </glossentry>
@ -1839,7 +1846,7 @@
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> <!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
Specifies the flags to pass to the C compiler when building Specifies the flags to pass to the C compiler when building
for the SDK. for the SDK.
When building in the <filename>nativesdk</filename> When building in the <filename>nativesdk-</filename>
context, context,
<link linkend='var-CFLAGS'><filename>CFLAGS</filename></link> <link linkend='var-CFLAGS'><filename>CFLAGS</filename></link>
is set to the value of this variable by default. is set to the value of this variable by default.
@ -1857,7 +1864,7 @@
Specifies the flags to pass to the C pre-processor Specifies the flags to pass to the C pre-processor
(i.e. to both the C and the C++ compilers) when building (i.e. to both the C and the C++ compilers) when building
for the SDK. for the SDK.
When building in the <filename>nativesdk</filename> When building in the <filename>nativesdk-</filename>
context, context,
<link linkend='var-CPPFLAGS'><filename>CPPFLAGS</filename></link> <link linkend='var-CPPFLAGS'><filename>CPPFLAGS</filename></link>
is set to the value of this variable by default. is set to the value of this variable by default.
@ -1874,7 +1881,7 @@
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> <!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
Specifies the flags to pass to the C++ compiler when Specifies the flags to pass to the C++ compiler when
building for the SDK. building for the SDK.
When building in the <filename>nativesdk</filename> When building in the <filename>nativesdk-</filename>
context, context,
<link linkend='var-CXXFLAGS'><filename>CXXFLAGS</filename></link> <link linkend='var-CXXFLAGS'><filename>CXXFLAGS</filename></link>
is set to the value of this variable by default. is set to the value of this variable by default.
@ -2031,7 +2038,7 @@
and then can be used as an override. and then can be used as an override.
Here is an example where "python-native" is added to Here is an example where "python-native" is added to
<link linkend='var-DEPENDS'><filename>DEPENDS</filename></link> <link linkend='var-DEPENDS'><filename>DEPENDS</filename></link>
only when building for the native case: only when building for the <filename>-native</filename> case:
<literallayout class='monospaced'> <literallayout class='monospaced'>
DEPENDS_append_class-native = " python-native" DEPENDS_append_class-native = " python-native"
</literallayout> </literallayout>
@ -2567,7 +2574,7 @@
<listitem><para> <listitem><para>
<link linkend='var-BUILDSDK_CXXFLAGS'><filename>BUILDSDK_CXXFLAGS</filename></link> <link linkend='var-BUILDSDK_CXXFLAGS'><filename>BUILDSDK_CXXFLAGS</filename></link>
when building for an SDK (i.e. when building for an SDK (i.e.
<filename>nativesdk</filename>) <filename>nativesdk-</filename>)
</para></listitem> </para></listitem>
</itemizedlist> </itemizedlist>
</para> </para>
@ -4736,12 +4743,12 @@
<listitem><para> <listitem><para>
<filename>BUILD_CC_ARCH</filename> <filename>BUILD_CC_ARCH</filename>
when building for the build host (i.e. when building for the build host (i.e.
<filename>native</filename>) <filename>-native</filename>)
</para></listitem> </para></listitem>
<listitem><para> <listitem><para>
<filename>BUILDSDK_CC_ARCH</filename> <filename>BUILDSDK_CC_ARCH</filename>
when building for an SDK (i.e. when building for an SDK (i.e.
<filename>nativesdk</filename>) <filename>nativesdk-</filename>)
</para></listitem> </para></listitem>
</itemizedlist> </itemizedlist>
</para> </para>
@ -11898,14 +11905,14 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
<listitem><para>For recipes building for the target <listitem><para>For recipes building for the target
machine, the value is "${STAGING_DIR}/${MACHINE}". machine, the value is "${STAGING_DIR}/${MACHINE}".
</para></listitem> </para></listitem>
<listitem><para>For <filename>native</filename> <listitem><para>For native recipes building
recipes building
for the build host, the value is empty given the for the build host, the value is empty given the
assumption that when building for the build host, assumption that when building for the build host,
the build host's own directories should be used. the build host's own directories should be used.
</para></listitem> </para></listitem>
<listitem><para>For <filename>nativesdk</filename> <listitem><para>For native SDK
recipes that build for the SDK, the value is recipes that build for the SDK
(<filename>nativesdk</filename>), the value is
"${STAGING_DIR}/${MULTIMACH_HOST_SYS}". "${STAGING_DIR}/${MULTIMACH_HOST_SYS}".
</para></listitem> </para></listitem>
</itemizedlist> </itemizedlist>
@ -12713,12 +12720,13 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
"${<link linkend='var-TARGET_SYS'>TARGET_SYS</link>}-". "${<link linkend='var-TARGET_SYS'>TARGET_SYS</link>}-".
</para></listitem> </para></listitem>
<listitem><para> <listitem><para>
For <filename>native</filename> recipes, the build For native recipes, the build system sets the
system sets the variable to the value of variable to the value of
<filename>BUILD_PREFIX</filename>. <filename>BUILD_PREFIX</filename>.
</para></listitem> </para></listitem>
<listitem><para> <listitem><para>
For <filename>nativesdk</filename> recipes, the For native SDK recipes
(<filename>nativesdk</filename>), the
build system sets the variable to the value of build system sets the variable to the value of
<filename>SDK_PREFIX</filename>. <filename>SDK_PREFIX</filename>.
</para></listitem> </para></listitem>
@ -12757,9 +12765,8 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
Consider these two examples: Consider these two examples:
<itemizedlist> <itemizedlist>
<listitem><para> <listitem><para>
Given a <filename>native</filename> recipe on a Given a native recipe on a 32-bit, x86 machine
32-bit, x86 machine running Linux, the value is running Linux, the value is "i686-linux".
"i686-linux".
</para></listitem> </para></listitem>
<listitem><para> <listitem><para>
Given a recipe being built for a little-endian, Given a recipe being built for a little-endian,
@ -13365,11 +13372,14 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
toolchain set that runs on the toolchain set that runs on the
<link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>, <link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>,
and each package should usually have the prefix and each package should usually have the prefix
"nativesdk-". <filename>nativesdk-</filename>.
When building an SDK using For example, consider the following command when
<filename>bitbake -c populate_sdk &lt;imagename&gt;</filename>, building an SDK:
a default list of packages is set in this variable, but <literallayout class='monospaced'>
you can add additional packages to the list. $ bitbake -c populate_sdk <replaceable>imagename</replaceable>
</literallayout>
In this case, a default list of packages is set in this
variable, but you can add additional packages to the list.
</para> </para>
<para> <para>

18
documentation/ref-manual/technical-details.xml
View File

@ -470,17 +470,19 @@
</para> </para>
<para> <para>
To complicate the problem, there are things that should not be included in To complicate the problem, there are things that should not be
the checksum. included in the checksum.
First, there is the actual specific build path of a given task - First, there is the actual specific build path of a given task -
the <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>. the <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>.
It does not matter if the work directory changes because it should not It does not matter if the work directory changes because it should
affect the output for target packages. not affect the output for target packages.
Also, the build process has the objective of making native or cross packages relocatable. Also, the build process has the objective of making native
The checksum therefore needs to exclude <filename>WORKDIR</filename>. (build host) or cross packages (target hardware) relocatable.
The checksum therefore needs to exclude
<filename>WORKDIR</filename>.
The simplistic approach for excluding the work directory is to set The simplistic approach for excluding the work directory is to set
<filename>WORKDIR</filename> to some fixed value and create the checksum <filename>WORKDIR</filename> to some fixed value and create the
for the "run" script. checksum for the "run" script.
</para> </para>
<para> <para>