mirror of
https://git.yoctoproject.org/poky
synced 2026-05-09 17:39:31 +00:00
manuals: define proper numbered lists
Using "#." instead of "1.", "2.", "3.", etc. (From yocto-docs rev: 11c2585acd0fa6c330702af2359ce5a9e47cde1f) Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com> Reported-by: Quentin Schulz <foss+yocto@0leil.net> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Michael Opdenacker
committed by
Richard Purdie
Richard Purdie
parent
474e071608
commit
6846d4d00b
@@ -173,12 +173,12 @@ perform additional steps. These steps make it possible for anyone using
|
||||
the installed SDKs to update the installed SDKs by using the
|
||||
``devtool sdk-update`` command:
|
||||
|
||||
1. Create a directory that can be shared over HTTP or HTTPS. You can do
|
||||
#. Create a directory that can be shared over HTTP or HTTPS. You can do
|
||||
this by setting up a web server such as an :wikipedia:`Apache HTTP Server
|
||||
<Apache_HTTP_Server>` or :wikipedia:`Nginx <Nginx>` server in the cloud
|
||||
to host the directory. This directory must contain the published SDK.
|
||||
|
||||
2. Set the
|
||||
#. Set the
|
||||
:term:`SDK_UPDATE_URL`
|
||||
variable to point to the corresponding HTTP or HTTPS URL. Setting
|
||||
this variable causes any SDK built to default to that URL and thus,
|
||||
@@ -187,10 +187,10 @@ the installed SDKs to update the installed SDKs by using the
|
||||
":ref:`sdk-manual/extensible:applying updates to an installed extensible sdk`"
|
||||
section.
|
||||
|
||||
3. Build the extensible SDK normally (i.e., use the
|
||||
#. Build the extensible SDK normally (i.e., use the
|
||||
``bitbake -c populate_sdk_ext`` imagename command).
|
||||
|
||||
4. Publish the SDK using the following command::
|
||||
#. Publish the SDK using the following command::
|
||||
|
||||
$ oe-publish-sdk some_path/sdk-installer.sh path_to_shared_http_directory
|
||||
|
||||
@@ -245,7 +245,7 @@ If you want the users of an extensible SDK you build to be able to add
|
||||
items to the SDK without requiring the users to build the items from
|
||||
source, you need to do a number of things:
|
||||
|
||||
1. Ensure the additional items you want the user to be able to install
|
||||
#. Ensure the additional items you want the user to be able to install
|
||||
are already built:
|
||||
|
||||
- Build the items explicitly. You could use one or more "meta"
|
||||
@@ -257,12 +257,12 @@ source, you need to do a number of things:
|
||||
:term:`EXCLUDE_FROM_WORLD`
|
||||
variable for additional information.
|
||||
|
||||
2. Expose the ``sstate-cache`` directory produced by the build.
|
||||
#. Expose the ``sstate-cache`` directory produced by the build.
|
||||
Typically, you expose this directory by making it available through
|
||||
an :wikipedia:`Apache HTTP Server <Apache_HTTP_Server>` or
|
||||
:wikipedia:`Nginx <Nginx>` server.
|
||||
|
||||
3. Set the appropriate configuration so that the produced SDK knows how
|
||||
#. Set the appropriate configuration so that the produced SDK knows how
|
||||
to find the configuration. The variable you need to set is
|
||||
:term:`SSTATE_MIRRORS`::
|
||||
|
||||
|
||||
@@ -28,14 +28,14 @@ and then run the script to hand-install the toolchain.
|
||||
|
||||
Follow these steps to locate and hand-install the toolchain:
|
||||
|
||||
1. *Go to the Installers Directory:* Go to
|
||||
#. *Go to the Installers Directory:* Go to
|
||||
:yocto_dl:`/releases/yocto/yocto-&DISTRO;/toolchain/`
|
||||
|
||||
2. *Open the Folder for Your Build Host:* Open the folder that matches
|
||||
#. *Open the Folder for Your Build Host:* Open the folder that matches
|
||||
your :term:`Build Host` (i.e.
|
||||
``i686`` for 32-bit machines or ``x86_64`` for 64-bit machines).
|
||||
|
||||
3. *Locate and Download the SDK Installer:* You need to find and
|
||||
#. *Locate and Download the SDK Installer:* You need to find and
|
||||
download the installer appropriate for your build host, target
|
||||
hardware, and image type.
|
||||
|
||||
@@ -72,7 +72,7 @@ Follow these steps to locate and hand-install the toolchain:
|
||||
|
||||
poky-glibc-x86_64-core-image-sato-core2-64-toolchain-ext-&DISTRO;.sh
|
||||
|
||||
4. *Run the Installer:* Be sure you have execution privileges and run
|
||||
#. *Run the Installer:* Be sure you have execution privileges and run
|
||||
the installer. Following is an example from the ``Downloads``
|
||||
directory::
|
||||
|
||||
@@ -91,13 +91,13 @@ Building an SDK Installer
|
||||
As an alternative to locating and downloading an SDK installer, you can
|
||||
build the SDK installer. Follow these steps:
|
||||
|
||||
1. *Set Up the Build Environment:* Be sure you are set up to use BitBake
|
||||
#. *Set Up the Build Environment:* Be sure you are set up to use BitBake
|
||||
in a shell. See the ":ref:`dev-manual/start:preparing the build host`" section
|
||||
in the Yocto Project Development Tasks Manual for information on how
|
||||
to get a build host ready that is either a native Linux machine or a
|
||||
machine that uses CROPS.
|
||||
|
||||
2. *Clone the ``poky`` Repository:* You need to have a local copy of the
|
||||
#. *Clone the ``poky`` Repository:* You need to have a local copy of the
|
||||
Yocto Project :term:`Source Directory`
|
||||
(i.e. a local
|
||||
``poky`` repository). See the ":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`" and
|
||||
@@ -107,7 +107,7 @@ build the SDK installer. Follow these steps:
|
||||
how to clone the ``poky`` repository and check out the appropriate
|
||||
branch for your work.
|
||||
|
||||
3. *Initialize the Build Environment:* While in the root directory of
|
||||
#. *Initialize the Build Environment:* While in the root directory of
|
||||
the Source Directory (i.e. ``poky``), run the
|
||||
:ref:`structure-core-script` environment
|
||||
setup script to define the OpenEmbedded build environment on your
|
||||
@@ -120,12 +120,12 @@ build the SDK installer. Follow these steps:
|
||||
the script runs, your current working directory is set to the ``build``
|
||||
directory.
|
||||
|
||||
4. *Make Sure You Are Building an Installer for the Correct Machine:*
|
||||
#. *Make Sure You Are Building an Installer for the Correct Machine:*
|
||||
Check to be sure that your :term:`MACHINE` variable in the ``local.conf``
|
||||
file in your :term:`Build Directory` matches the architecture
|
||||
for which you are building.
|
||||
|
||||
5. *Make Sure Your SDK Machine is Correctly Set:* If you are building a
|
||||
#. *Make Sure Your SDK Machine is Correctly Set:* If you are building a
|
||||
toolchain designed to run on an architecture that differs from your
|
||||
current development host machine (i.e. the build host), be sure that
|
||||
the :term:`SDKMACHINE` variable in the ``local.conf`` file in your
|
||||
@@ -145,7 +145,7 @@ build the SDK installer. Follow these steps:
|
||||
different from the architecture of the build machine (``x86_64``).
|
||||
|
||||
|
||||
6. *Build the SDK Installer:* To build the SDK installer for a standard
|
||||
#. *Build the SDK Installer:* To build the SDK installer for a standard
|
||||
SDK and populate the SDK image, use the following command form. Be
|
||||
sure to replace ``image`` with an image (e.g. "core-image-sato")::
|
||||
|
||||
@@ -175,7 +175,7 @@ build the SDK installer. Follow these steps:
|
||||
static development libraries: TOOLCHAIN_TARGET_TASK:append = "
|
||||
libc-staticdev"
|
||||
|
||||
7. *Run the Installer:* You can now run the SDK installer from
|
||||
#. *Run the Installer:* You can now run the SDK installer from
|
||||
``tmp/deploy/sdk`` in the :term:`Build Directory`. Following is an example::
|
||||
|
||||
$ cd poky/build/tmp/deploy/sdk
|
||||
@@ -203,7 +203,7 @@ separately extract a root filesystem:
|
||||
|
||||
Follow these steps to extract the root filesystem:
|
||||
|
||||
1. *Locate and Download the Tarball for the Pre-Built Root Filesystem
|
||||
#. *Locate and Download the Tarball for the Pre-Built Root Filesystem
|
||||
Image File:* You need to find and download the root filesystem image
|
||||
file that is appropriate for your target system. These files are kept
|
||||
in machine-specific folders in the
|
||||
@@ -241,7 +241,7 @@ Follow these steps to extract the root filesystem:
|
||||
|
||||
core-image-sato-sdk-beaglebone-yocto.tar.bz2
|
||||
|
||||
2. *Initialize the Cross-Development Environment:* You must ``source``
|
||||
#. *Initialize the Cross-Development Environment:* You must ``source``
|
||||
the cross-development environment setup script to establish necessary
|
||||
environment variables.
|
||||
|
||||
@@ -253,7 +253,7 @@ Follow these steps to extract the root filesystem:
|
||||
|
||||
$ source poky_sdk/environment-setup-core2-64-poky-linux
|
||||
|
||||
3. *Extract the Root Filesystem:* Use the ``runqemu-extract-sdk``
|
||||
#. *Extract the Root Filesystem:* Use the ``runqemu-extract-sdk``
|
||||
command and provide the root filesystem image.
|
||||
|
||||
Following is an example command that extracts the root filesystem
|
||||
|
||||
@@ -47,7 +47,7 @@ Two ways to install the Extensible SDK
|
||||
Extensible SDK can be installed in two different ways, and both have
|
||||
their own pros and cons:
|
||||
|
||||
1. *Setting up the Extensible SDK environment directly in a Yocto build*. This
|
||||
#. *Setting up the Extensible SDK environment directly in a Yocto build*. This
|
||||
avoids having to produce, test, distribute and maintain separate SDK installer
|
||||
archives, which can get very large. There is only one environment for the regular
|
||||
Yocto build and the SDK and less code paths where things can go not according to plan.
|
||||
@@ -56,7 +56,7 @@ git fetch or layer management tooling. The SDK extensibility is better than in t
|
||||
second option: just run ``bitbake`` again to add more things to the sysroot, or add layers
|
||||
if even more things are required.
|
||||
|
||||
2. *Setting up the Extensible SDK from a standalone installer*. This has the benefit of
|
||||
#. *Setting up the Extensible SDK from a standalone installer*. This has the benefit of
|
||||
having a single, self-contained archive that includes all the needed binary artifacts.
|
||||
So nothing needs to be rebuilt, and there is no need to provide a well-functioning
|
||||
binary artefact cache over the network for developers with underpowered laptops.
|
||||
@@ -64,10 +64,10 @@ binary artefact cache over the network for developers with underpowered laptops.
|
||||
Setting up the Extensible SDK environment directly in a Yocto build
|
||||
-------------------------------------------------------------------
|
||||
|
||||
1. Set up all the needed layers and a Yocto :term:`Build Directory`, e.g. a regular Yocto
|
||||
#. Set up all the needed layers and a Yocto :term:`Build Directory`, e.g. a regular Yocto
|
||||
build where ``bitbake`` can be executed.
|
||||
|
||||
2. Run:
|
||||
#. Run:
|
||||
$ bitbake meta-ide-support
|
||||
$ bitbake -c populate_sysroot gtk+3
|
||||
(or any other target or native item that the application developer would need)
|
||||
@@ -279,7 +279,7 @@ command:
|
||||
.. image:: figures/sdk-devtool-add-flow.png
|
||||
:width: 100%
|
||||
|
||||
1. *Generating the New Recipe*: The top part of the flow shows three
|
||||
#. *Generating the New Recipe*: The top part of the flow shows three
|
||||
scenarios by which you could use ``devtool add`` to generate a recipe
|
||||
based on existing source code.
|
||||
|
||||
@@ -352,7 +352,7 @@ command:
|
||||
Aside from a recipe folder, the command also creates an associated
|
||||
append folder and places an initial ``*.bbappend`` file within.
|
||||
|
||||
2. *Edit the Recipe*: You can use ``devtool edit-recipe`` to open up the
|
||||
#. *Edit the Recipe*: You can use ``devtool edit-recipe`` to open up the
|
||||
editor as defined by the ``$EDITOR`` environment variable and modify
|
||||
the file::
|
||||
|
||||
@@ -362,7 +362,7 @@ command:
|
||||
can make modifications to the recipe that take effect when you build
|
||||
it later.
|
||||
|
||||
3. *Build the Recipe or Rebuild the Image*: The next step you take
|
||||
#. *Build the Recipe or Rebuild the Image*: The next step you take
|
||||
depends on what you are going to do with the new code.
|
||||
|
||||
If you need to eventually move the build output to the target
|
||||
@@ -378,7 +378,7 @@ command:
|
||||
|
||||
$ devtool build-image image
|
||||
|
||||
4. *Deploy the Build Output*: When you use the ``devtool build`` command
|
||||
#. *Deploy the Build Output*: When you use the ``devtool build`` command
|
||||
to build out your recipe, you probably want to see if the resulting
|
||||
build output works as expected on the target hardware.
|
||||
|
||||
@@ -400,7 +400,7 @@ command:
|
||||
``devtool`` does not provide a specific command that allows you to
|
||||
deploy the image to actual hardware.
|
||||
|
||||
5. *Finish Your Work With the Recipe*: The ``devtool finish`` command
|
||||
#. *Finish Your Work With the Recipe*: The ``devtool finish`` command
|
||||
creates any patches corresponding to commits in the local Git
|
||||
repository, moves the new recipe to a more permanent layer, and then
|
||||
resets the recipe so that the recipe is built normally rather than
|
||||
@@ -446,7 +446,7 @@ command:
|
||||
.. image:: figures/sdk-devtool-modify-flow.png
|
||||
:width: 100%
|
||||
|
||||
1. *Preparing to Modify the Code*: The top part of the flow shows three
|
||||
#. *Preparing to Modify the Code*: The top part of the flow shows three
|
||||
scenarios by which you could use ``devtool modify`` to prepare to
|
||||
work on source files. Each scenario assumes the following:
|
||||
|
||||
@@ -555,11 +555,11 @@ command:
|
||||
append file for the recipe in the ``devtool`` workspace. The
|
||||
recipe and the source code remain in their original locations.
|
||||
|
||||
2. *Edit the Source*: Once you have used the ``devtool modify`` command,
|
||||
#. *Edit the Source*: Once you have used the ``devtool modify`` command,
|
||||
you are free to make changes to the source files. You can use any
|
||||
editor you like to make and save your source code modifications.
|
||||
|
||||
3. *Build the Recipe or Rebuild the Image*: The next step you take
|
||||
#. *Build the Recipe or Rebuild the Image*: The next step you take
|
||||
depends on what you are going to do with the new code.
|
||||
|
||||
If you need to eventually move the build output to the target
|
||||
@@ -572,7 +572,7 @@ command:
|
||||
(e.g. for testing purposes), you can use the ``devtool build-image``
|
||||
command: $ devtool build-image image
|
||||
|
||||
4. *Deploy the Build Output*: When you use the ``devtool build`` command
|
||||
#. *Deploy the Build Output*: When you use the ``devtool build`` command
|
||||
to build out your recipe, you probably want to see if the resulting
|
||||
build output works as expected on target hardware.
|
||||
|
||||
@@ -597,7 +597,7 @@ command:
|
||||
``devtool`` does not provide a specific command to deploy the image
|
||||
to actual hardware.
|
||||
|
||||
5. *Finish Your Work With the Recipe*: The ``devtool finish`` command
|
||||
#. *Finish Your Work With the Recipe*: The ``devtool finish`` command
|
||||
creates any patches corresponding to commits in the local Git
|
||||
repository, updates the recipe to point to them (or creates a
|
||||
``.bbappend`` file to do so, depending on the specified destination
|
||||
@@ -664,7 +664,7 @@ The following diagram shows the common development flow used with the
|
||||
.. image:: figures/sdk-devtool-upgrade-flow.png
|
||||
:width: 100%
|
||||
|
||||
1. *Initiate the Upgrade*: The top part of the flow shows the typical
|
||||
#. *Initiate the Upgrade*: The top part of the flow shows the typical
|
||||
scenario by which you use the ``devtool upgrade`` command. The
|
||||
following conditions exist:
|
||||
|
||||
@@ -716,7 +716,7 @@ The following diagram shows the common development flow used with the
|
||||
are incorporated into the build the next time you build the software
|
||||
just as are other changes you might have made to the source.
|
||||
|
||||
2. *Resolve any Conflicts created by the Upgrade*: Conflicts could happen
|
||||
#. *Resolve any Conflicts created by the Upgrade*: Conflicts could happen
|
||||
after upgrading the software to a new version. Conflicts occur
|
||||
if your recipe specifies some patch files in :term:`SRC_URI` that
|
||||
conflict with changes made in the new version of the software. For
|
||||
@@ -727,7 +727,7 @@ The following diagram shows the common development flow used with the
|
||||
conflicts created through use of a newer or different version of the
|
||||
software.
|
||||
|
||||
3. *Build the Recipe or Rebuild the Image*: The next step you take
|
||||
#. *Build the Recipe or Rebuild the Image*: The next step you take
|
||||
depends on what you are going to do with the new code.
|
||||
|
||||
If you need to eventually move the build output to the target
|
||||
@@ -742,7 +742,7 @@ The following diagram shows the common development flow used with the
|
||||
|
||||
$ devtool build-image image
|
||||
|
||||
4. *Deploy the Build Output*: When you use the ``devtool build`` command
|
||||
#. *Deploy the Build Output*: When you use the ``devtool build`` command
|
||||
or ``bitbake`` to build your recipe, you probably want to see if the
|
||||
resulting build output works as expected on target hardware.
|
||||
|
||||
@@ -764,7 +764,7 @@ The following diagram shows the common development flow used with the
|
||||
``devtool`` does not provide a specific command that allows you to do
|
||||
this.
|
||||
|
||||
5. *Finish Your Work With the Recipe*: The ``devtool finish`` command
|
||||
#. *Finish Your Work With the Recipe*: The ``devtool finish`` command
|
||||
creates any patches corresponding to commits in the local Git
|
||||
repository, moves the new recipe to a more permanent layer, and then
|
||||
resets the recipe so that the recipe is built normally rather than
|
||||
@@ -1054,17 +1054,17 @@ Working With Recipes
|
||||
When building a recipe using the ``devtool build`` command, the typical
|
||||
build progresses as follows:
|
||||
|
||||
1. Fetch the source
|
||||
#. Fetch the source
|
||||
|
||||
2. Unpack the source
|
||||
#. Unpack the source
|
||||
|
||||
3. Configure the source
|
||||
#. Configure the source
|
||||
|
||||
4. Compile the source
|
||||
#. Compile the source
|
||||
|
||||
5. Install the build output
|
||||
#. Install the build output
|
||||
|
||||
6. Package the installed output
|
||||
#. Package the installed output
|
||||
|
||||
For recipes in the workspace, fetching and unpacking is disabled as the
|
||||
source tree has already been prepared and is persistent. Each of these
|
||||
@@ -1322,15 +1322,15 @@ those customers need an SDK that has custom libraries. In such a case,
|
||||
you can produce a derivative SDK based on the currently installed SDK
|
||||
fairly easily by following these steps:
|
||||
|
||||
1. If necessary, install an extensible SDK that you want to use as a
|
||||
#. If necessary, install an extensible SDK that you want to use as a
|
||||
base for your derivative SDK.
|
||||
|
||||
2. Source the environment script for the SDK.
|
||||
#. Source the environment script for the SDK.
|
||||
|
||||
3. Add the extra libraries or other components you want by using the
|
||||
#. Add the extra libraries or other components you want by using the
|
||||
``devtool add`` command.
|
||||
|
||||
4. Run the ``devtool build-sdk`` command.
|
||||
#. Run the ``devtool build-sdk`` command.
|
||||
|
||||
The previous steps take the recipes added to the workspace and construct
|
||||
a new SDK installer that contains those recipes and the resulting binary
|
||||
|
||||
@@ -164,11 +164,11 @@ image.
|
||||
|
||||
You just need to follow these general steps:
|
||||
|
||||
1. *Install the SDK for your target hardware:* For information on how to
|
||||
#. *Install the SDK for your target hardware:* For information on how to
|
||||
install the SDK, see the ":ref:`sdk-manual/using:installing the sdk`"
|
||||
section.
|
||||
|
||||
2. *Download or Build the Target Image:* The Yocto Project supports
|
||||
#. *Download or Build the Target Image:* The Yocto Project supports
|
||||
several target architectures and has many pre-built kernel images and
|
||||
root filesystem images.
|
||||
|
||||
@@ -195,7 +195,7 @@ You just need to follow these general steps:
|
||||
":ref:`sdk-manual/appendix-obtain:extracting the root filesystem`"
|
||||
section for information on how to do this extraction.
|
||||
|
||||
3. *Develop and Test your Application:* At this point, you have the
|
||||
#. *Develop and Test your Application:* At this point, you have the
|
||||
tools to develop your application. If you need to separately install
|
||||
and use the QEMU emulator, you can go to `QEMU Home
|
||||
Page <https://wiki.qemu.org/Main_Page>`__ to download and learn about
|
||||
|
||||
@@ -31,7 +31,7 @@ project:
|
||||
GNOME Developer
|
||||
site.
|
||||
|
||||
1. *Create a Working Directory and Populate It:* Create a clean
|
||||
#. *Create a Working Directory and Populate It:* Create a clean
|
||||
directory for your project and then make that directory your working
|
||||
location::
|
||||
|
||||
@@ -74,7 +74,7 @@ project:
|
||||
bin_PROGRAMS = hello
|
||||
hello_SOURCES = hello.c
|
||||
|
||||
2. *Source the Cross-Toolchain Environment Setup File:* As described
|
||||
#. *Source the Cross-Toolchain Environment Setup File:* As described
|
||||
earlier in the manual, installing the cross-toolchain creates a
|
||||
cross-toolchain environment setup script in the directory that the
|
||||
SDK was installed. Before you can use the tools to develop your
|
||||
@@ -92,7 +92,7 @@ project:
|
||||
|
||||
$ source tmp/deploy/images/qemux86-64/environment-setup-core2-64-poky-linux
|
||||
|
||||
3. *Create the configure Script:* Use the ``autoreconf`` command to
|
||||
#. *Create the configure Script:* Use the ``autoreconf`` command to
|
||||
generate the ``configure`` script::
|
||||
|
||||
$ autoreconf
|
||||
@@ -108,7 +108,7 @@ project:
|
||||
which ensures missing auxiliary files are copied to the build
|
||||
host.
|
||||
|
||||
4. *Cross-Compile the Project:* This command compiles the project using
|
||||
#. *Cross-Compile the Project:* This command compiles the project using
|
||||
the cross-compiler. The
|
||||
:term:`CONFIGURE_FLAGS`
|
||||
environment variable provides the minimal arguments for GNU
|
||||
@@ -129,7 +129,7 @@ project:
|
||||
|
||||
$ ./configure --host=armv5te-poky-linux-gnueabi --with-libtool-sysroot=sysroot_dir
|
||||
|
||||
5. *Make and Install the Project:* These two commands generate and
|
||||
#. *Make and Install the Project:* These two commands generate and
|
||||
install the project into the destination directory::
|
||||
|
||||
$ make
|
||||
@@ -149,7 +149,7 @@ project:
|
||||
|
||||
$ file ./tmp/usr/local/bin/hello
|
||||
|
||||
6. *Execute Your Project:* To execute the project, you would need to run
|
||||
#. *Execute Your Project:* To execute the project, you would need to run
|
||||
it on your target hardware. If your target hardware happens to be
|
||||
your build host, you could run the project as follows::
|
||||
|
||||
@@ -227,7 +227,7 @@ established through the script::
|
||||
To illustrate variable use, work through this simple "Hello World!"
|
||||
example:
|
||||
|
||||
1. *Create a Working Directory and Populate It:* Create a clean
|
||||
#. *Create a Working Directory and Populate It:* Create a clean
|
||||
directory for your project and then make that directory your working
|
||||
location::
|
||||
|
||||
@@ -266,7 +266,7 @@ example:
|
||||
printf("\n");
|
||||
}
|
||||
|
||||
2. *Source the Cross-Toolchain Environment Setup File:* As described
|
||||
#. *Source the Cross-Toolchain Environment Setup File:* As described
|
||||
earlier in the manual, installing the cross-toolchain creates a
|
||||
cross-toolchain environment setup script in the directory that the
|
||||
SDK was installed. Before you can use the tools to develop your
|
||||
@@ -284,7 +284,7 @@ example:
|
||||
|
||||
$ source tmp/deploy/images/qemux86-64/environment-setup-core2-64-poky-linux
|
||||
|
||||
3. *Create the Makefile:* For this example, the Makefile contains
|
||||
#. *Create the Makefile:* For this example, the Makefile contains
|
||||
two lines that can be used to set the :term:`CC` variable. One line is
|
||||
identical to the value that is set when you run the SDK environment
|
||||
setup script, and the other line sets :term:`CC` to "gcc", the default
|
||||
@@ -302,7 +302,7 @@ example:
|
||||
rm -rf *.o
|
||||
rm target_bin
|
||||
|
||||
4. *Make the Project:* Use the ``make`` command to create the binary
|
||||
#. *Make the Project:* Use the ``make`` command to create the binary
|
||||
output file. Because variables are commented out in the Makefile, the
|
||||
value used for :term:`CC` is the value set when the SDK environment setup
|
||||
file was run::
|
||||
@@ -387,7 +387,7 @@ example:
|
||||
use the SDK environment variables regardless of the values in the
|
||||
Makefile.
|
||||
|
||||
5. *Execute Your Project:* To execute the project (i.e. ``target_bin``),
|
||||
#. *Execute Your Project:* To execute the project (i.e. ``target_bin``),
|
||||
use the following command::
|
||||
|
||||
$ ./target_bin
|
||||
|
||||
Reference in New Issue
Block a user