doc: build system updates

Change-Id: Ifbe4dcad0ecf0a3ceb0de9ed83b4f70246e26e72
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
This commit is contained in:
Anas Nashif 2015-10-18 12:18:06 -04:00
commit bc6b6100ec
3 changed files with 14 additions and 169 deletions

View file

@ -67,20 +67,15 @@ Default Configurations
======================
The default configuration files define the default configuration for a specific
kernel on a specific platform. For example: :file:`arch/arm/configs`,
:file:`arch/x86/configs` and :file:`arch/arc/configs`.
kernel on a specific platform. For example:
The file name convention for a :abbr:`defconfig (default configuration)` file
mandates that the type of kernel and the platform are included within the file
name. Further, all the defconfig files must end with the suffix defconfig. For
example, the :file:`micro_galileo_defconfig` file contains the configuration
information for the microkernel architecture for the galileo platform
configuration and the :file:`nano_basic_atom_defconfig` file contains the
configuration information for the nanokernel architecture for the basic atom
platform.
* :file:`arch/arm/configs`,
* :file:`arch/x86/configs` and
* :file:`arch/arc/configs`.
The defconfig files are used to dynamically determine the configuration that
corresponds to the platform tested by the sanity checks.
All the defconfig files must end with the suffix defconfig. For
example, the :file:`galileo_defconfig` file contains the configuration
information for the galileo platform.
The :file:`Makefile.inc` file uses defconfig files to provide a clean interface
to developers using environment variables to define the kernel type and the
@ -91,9 +86,9 @@ example:
.. code-block:: bash
$ make defconfig micro_galileo_defconfig
$ make galileo_defconfig
The command takes the default configuration for the microkernel architecture
The command takes the default configuration for the architecture
and the galileo platform configuration to compile the kernel.
.. _configuration_snippets:
@ -101,7 +96,7 @@ and the galileo platform configuration to compile the kernel.
Merging Configuration Fragments
===============================
Configuration file snippets can be merged with the current project
Configuration file fragment can be merged with the current project
configuration during the build.
Developers can provide a configuration file that defines a small subset of
@ -116,6 +111,6 @@ world** overrides the base configuration with the configuration snippet
.. caution::
Invalid configurations, or configurations that do not comply with
the dependencies stated in the Kconfig files, are ignored by the merge process.
When adding configuration options through a configuration snippet, ensure that
the the complete sequence complies with the dependency rules defined in the
When adding configuration options through a configuration fragment, ensure that
the complete sequence complies with the dependency rules defined in the
Kconfig files.

View file

@ -10,7 +10,7 @@ The build system defines a set of conventions for the correct use of Makefiles i
directories. The correct use of Makefiles is driven by the concept of recursion.
In the recursion model, each Makefile within a directory includes the source code and any
subdirectories to the build process. Each subdirectory follows the same principle. Developers can
sub-directories to the build process. Each sub-directory follows the same principle. Developers can
focus exclusively in their own work. They integrate their module with the build system by adding a
very simple Makefile following the recursive model.
@ -26,7 +26,7 @@ conventions guard the correct implementation of the recursive model.
considered source code directories.
* The scope of every Makefile is restricted to the contents of that directory. A Makefile can only
make a direct reference to its own files and subdirectories. Any file outside the directory has
make a direct reference to its own files and sub-directories. Any file outside the directory has
to be referenced in its home directory Makefile.
* Makefiles list the object files that are included in the link process. The build system finds the

View file

@ -1,152 +1,2 @@
.. _kbuild_toolchains:
Using Toolchains with Kbuild
****************************
The |project| gives support for the configuration of Yocto and XTools
toolchain and build tools. The environment variable
:envvar:`ZEPHYR_GCC_VARIANT` informs the build systen about which
build tool set is installed in the system and configures it as a standard
installation:
.. code-block:: bash
$ export ZEPHYR_GCC_VARIANT=zephyr
$ export ZEPHYR_GCC_VARIANT=xtools
The supported values for the :envvar:`ZEPHYR_GCC_VARIANT` variable are:
**zephyr** and **xtools**.
Yocto Configuration
===================
To set up a previously installed Zephyr toolchain in the build system,
you need to configure the Zephyr SDK installation path and the GCC
variant in the shell environment:
.. code-block:: bash
$ export ZEPHYR_SDK_INSTALL_DIR=<sdk-installation-path>
$ export ZEPHYR_GCC_VARIANT=zephyr
The build system configuration is done by the file
:file:`$(ZEPHYR_BASE)/scripts/Makefile.toochain.zephyr`. The build
system takes the following configuration values:
* x86 default configuration values
* Crosscompile target: i586-poky-elf
* Crosscompile version: 4.9.3
* Toolchain library: gcc
* ARM default configuration values
* Crosscompile target: arm-poky-eabi
* Crosscompile version: 5.2.0
* Toolchain library: gcc
* ARC default configuration values
* Crosscompile target: arc-poky-elf
* Crosscompile version: 4.8.3
* Toolchain library: gcc
The cross-compile target, cross-compile version, toolchain library and
library path can be adjusted in the file
:file:`$(ZEPHYR_BASE)/scripts/Makefile.toochain.zephyr` following your
installation specifics.
XTools Configuration
====================
To set up a previously-installed XTools toolchain in the build system,
you need to configure the XTools installation path and the GCC
variant in the shell environment:
.. code-block:: bash
$ export XTOOLS_TOOLCHAIN_PATH=<sdk-installation-path>
$ export ZEPHYR_GCC_VARIANT=xtools
The build system configuration is done by the file
:file:`$(ZEPHYR_BASE)/scripts/Makefile.toochain.xtools`. The build
system takes the following configuration values:
* x86 default configuration values
* Crosscompile target: i586-pc-elf
* Crosscompile version: 4.9.2
* Toolchain library: gcc
* ARM default configuration values
* Crosscompile target: arm-none-eabi
* Crosscompile version: 4.9.2
* Toolchain library: gcc
The cross-compile target, cross-compile version and toolchain
can be adjusted in the file
:file:`$(ZEPHYR_BASE)/scripts/Makefile.toochain.xtools` following your
installation specifics.
Generic Toolchain Configuration
===============================
It is possible to build and install an specific toolchain and configure
the build system to work with it. The **CROSS_COMPILE**,
**TOOLCHAIN_LIBS** and **LIB_INCLUDE_DIR** need to be configured in
your environment.
.. note::
The installed toolchain must be from the gcc family. The build tools
should follow the convention of: prefix + command-name. For example,
the gcc command should be named: **arm-poky-eabi-gcc**
The **CROSS_COMPILE** environment variable should be set to the
build tools prefix used for build tools commands.
.. code-block:: bash
$ export CROSS_COMPILE = i586-elf-
.. note::
If the command home directory is not set in the **PATH** environment
variable, the **CROSS_COMPILE** must include the complete path as
part of the command prefix.
The **TOOLCHAIN_LIBS** list the libraries required by the toolchain, like gcc
.
.. code-block:: bash
$ export TOOLCHAIN_LIBS = gcc
.. note::
Notice that there library name does not include the l prefix
commonly found when referring to libraries (lgcc).
**LIB_INCLUDE_DIR** defines the directory path where the toolchain
libraries can be located.
.. code-block:: bash
$ export LIB_INCLUDE_DIR = -L /opt/i586-elf/usr/lib/i586-elf/4.9
.. note::
Notice the use of the -L command parameter, included in the value
of the environment variable.