From d65d81e06d74cf3a032c3b04ccb68aff91638920 Mon Sep 17 00:00:00 2001 From: Ulf Samuelsson Date: Thu, 12 Jul 2007 16:53:13 +0000 Subject: Fix Document style --- docs/buildroot.html | 136 +++++++++++++++++++++++++++------------------------- 1 file changed, 71 insertions(+), 65 deletions(-) (limited to 'docs/buildroot.html') diff --git a/docs/buildroot.html b/docs/buildroot.html index 850e58d7a..c70b98576 100644 --- a/docs/buildroot.html +++ b/docs/buildroot.html @@ -34,7 +34,8 @@
  • Using the uClibc toolchain
  • Using the uClibc toolchain outside of Buildroot
    • -
  • Location of downloaded packages
    • +
  • Location of downloaded packages +
  • Extending Buildroot with more Software
  • Resources
    • @@ -68,8 +69,8 @@ uses the GNU libc as C standard library. This compilation toolchain is called the "host compilation toolchain", and more generally, the machine on which it is running, and on which you're - working is called the "host system". The compilation toolchain is - provided by your distribution, and Buildroot has nothing to do + working is called the "host system". The compilation toolchain + is provided by your distribution, and Buildroot has nothing to do with it.

    As said above, the compilation toolchain that comes with your system @@ -147,7 +148,7 @@

    One of the key configuration items is the PROJECT which determines where some board specific packages are built and where the - results are stored.

    + results are stored.

    Once everything is configured, the configuration tool has generated a .config file that contains the description of your @@ -165,7 +166,8 @@ be named root_fs_ARCH.EXT where ARCH is your architecture and EXT depends on the type of target filesystem selected in the Target options section of the configuration - tool.The file is stored in the "binaries/$(PROJECT)/" directory

    + tool. + The file is stored in the "binaries/$(PROJECT)/" directory

    If you intend to do an offline-build and just want to download all sources that you previously selected in "make menuconfig" then @@ -207,12 +209,12 @@ $ make HOSTCXX=g++-4.3-HEAD HOSTCC=gcc-4.3-HEAD

    @@ -258,8 +261,9 @@ $ make HOSTCXX=g++-4.3-HEAD HOSTCC=gcc-4.3-HEAD

    Otherwise, you can simply change the - package/busybox/busybox-<version>.config file if you know the options - you want to change without using the configuration tool.

    + package/busybox/busybox-<version>.config file if you + know the options you want to change without using the configuration tool. +

    If you want to use an existing config file for busybox, then see section environment variables.

    @@ -358,28 +362,28 @@ $ make HOSTCXX=g++-4.3-HEAD HOSTCC=gcc-4.3-HEAD tarballs are in this directory because it may be useful to save them somewhere to avoid further downloads. -
  • Create the shared build directory (build_ARCH/ by default, - where ARCH is your architecture). This is where all - non configurable user-space tools will be compiled.When building two or more - targets using the same architecture, the first build will go through the full - download, configure, make process, but the second and later builds will only - copy the result from the first build to its project specific target directory - significantly speeding up the build process
    • +
  • Create the shared build directory (build_ARCH/ by + default, where ARCH is your architecture). This is where all + non configurable user-space tools will be compiled.When building two or + more targets using the same architecture, the first build will go through + the full download, configure, make process, but the second and later + builds will only copy the result from the first build to its project + specific target directory significantly speeding up the build process
  • Create the project specific build directory - (project_build_ARCH/$(PROJECT) by default, where ARCH - is your architecture). This is where all configurable user-space tools will be - compiled. The project specific build directory is neccessary, if two different - targets needs to use a specific package, but the packages have different - configuration for both targets. Some examples of packages built in this directory - are busybox and linux. + (project_build_ARCH/$(PROJECT) by default, where + ARCH is your architecture). This is where all configurable + user-space tools will be compiled. The project specific build directory + is neccessary, if two different targets needs to use a specific package, + but the packages have different configuration for both targets. Some + examples of packages built in this directory are busybox and linux.
  • Create the project specific result directory (binaries/$(PROJECT) by default, where ARCH - is your architecture). This is where the root file system images are stored, - It is also used to store the linux kernel image and any utilities, boot-loaders - etc. needed for a target. + is your architecture). This is where the root file system images are + stored, It is also used to store the linux kernel image and any + utilities, boot-loaders etc. needed for a target.
  • Create the toolchain build directory @@ -456,9 +460,9 @@ mips-linux-gcc -o foo foo.c build_ARCH/staging_dir/. But sometimes, it may be useful to install it somewhere else, so that it can be used to compile other programs or by other users. Moving the build_ARCH/staging_dir/ - directory elsewhere is not possible if using gcc-3.x, because they are some hardcoded - paths in the toolchain configuration. This works, thanks to sysroot support, with current, - stable gcc-4.x toolchains, of course.

    + directory elsewhere is not possible if using gcc-3.x, because they + are some hardcoded paths in the toolchain configuration. This works, thanks + to sysroot support, with current, stable gcc-4.x toolchains, of course.

    If you want to use the generated gcc-3.x toolchain for other purposes, you can configure Buildroot to generate it elsewhere using the @@ -585,7 +589,8 @@ config BR2_PACKAGE_FOO the other *.mk files in the package directory.

    -

    At lines 6-11, a couple of useful variables are defined :

    +

    At lines 6-11, a couple of useful variables are + defined :

    -

    Lines 13-14 defines a target that downloads the tarball from - the remote site to the download directory +

    Lines 13-14 defines a target that downloads the + tarball from the remote site to the download directory (DL_DIR).

    -

    Lines 16-18 defines a target and associated rules that - uncompress the downloaded tarball. As you can see, this target +

    Lines 16-18 defines a target and associated rules + that uncompress the downloaded tarball. As you can see, this target depends on the tarball file, so that the previous target (line - 13-14) is called before executing the rules of the current - target. Uncompressing is followed by touching a hidden file + 13-14) is called before executing the rules of the + current target. Uncompressing is followed by touching a hidden file to mark the software has having been uncompressed. This trick is used everywhere in Buildroot Makefile to split steps (download, uncompress, configure, compile, install) while still having correct dependencies.

    -

    Lines 20-31 defines a target and associated rules that - configures the software. It depends on the previous target (the +

    Lines 20-31 defines a target and associated rules + that configures the software. It depends on the previous target (the hidden .source file) so that we are sure the software has been uncompressed. In order to configure it, it basically runs the well-known ./configure script. As we may be doing @@ -640,15 +645,15 @@ config BR2_PACKAGE_FOO filesystem. Finally it creates a .configured file to mark the software as configured.

    -

    Lines 33-34 defines a target and a rule that compiles the - software. This target will create the binary file in the +

    Lines 33-34 defines a target and a rule that + compiles the software. This target will create the binary file in the compilation directory, and depends on the software being already configured (hence the reference to the .configured file). It basically runs make inside the source directory.

    -

    Lines 36-38 defines a target and associated rules that install - the software inside the target filesystem. It depends on the +

    Lines 36-38 defines a target and associated rules + that install the software inside the target filesystem. It depends on the binary file in the source directory, to make sure the software has been compiled. It uses the install target of the software Makefile by passing a prefix @@ -658,8 +663,8 @@ config BR2_PACKAGE_FOO /usr/man directory inside the target filesystem is removed to save space.

    -

    Line 40 defines the main target of the software, the one - that will be eventually be used by the top level +

    Line 40 defines the main target of the software, + the one that will be eventually be used by the top level Makefile to download, compile, and then install this package. This target should first of all depends on all needed dependecies of the software (in our example, @@ -667,33 +672,34 @@ config BR2_PACKAGE_FOO final binary. This last dependency will call all previous dependencies in the correct order.

    -

    Line 42 defines a simple target that only downloads the code - source. This is not used during normal operation of Buildroot, but - is needed if you intend to download all required sources at once - for later offline build. Note that if you add a new package providing +

    Line 42 defines a simple target that only + downloads the code source. This is not used during normal operation of + Buildroot, but is needed if you intend to download all required sources at + once for later offline build. Note that if you add a new package providing a foo-source target is mandatory to support users that wish to do offline-builds. Furthermore it eases checking if all package-sources are downloadable.

    -

    Lines 44-46 define a simple target to clean the software build - by calling the Makefiles with the appropriate option. +

    Lines 44-46 define a simple target to clean the + software build by calling the Makefiles with the appropriate option. The -clean target should run make clean on $(BUILD_DIR)/package-version and MUST uninstall all files of the package from $(STAGING_DIR) and from $(TARGET_DIR).

    -

    Lines 48-49 define a simple target to completely remove the - directory in which the software was uncompressed, configured and - compiled. The -dirclean target MUST completely rm $(BUILD_DIR)/package-version.

    +

    Lines 48-49 define a simple target to completely + remove the directory in which the software was uncompressed, configured and + compiled. The -dirclean target MUST completely rm $(BUILD_DIR)/ + package-version.

    -

    Lines 51-58 adds the target foo to the list - of targets to be compiled by Buildroot by first checking if +

    Lines 51-58 adds the target foo to + the list of targets to be compiled by Buildroot by first checking if the configuration option for this package has been enabled using the configuration tool, and if so then "subscribes" this package to be compiled by adding it to the TARGETS global variable. The name added to the TARGETS global variable is the name of this package's target, as defined on - line 40, which is used by Buildroot to download, compile, and - then install this package.

    + line 40, which is used by Buildroot to download, + compile, and then install this package.

    Conclusion

    -- cgit v1.2.3