From: Peter Korsgaard Date: Tue, 16 Dec 2008 09:00:11 +0000 (-0000) Subject: docs/buildroot.html: misc small fixes and strip trailing spaces X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=ce85931015f21f21dd0f2624056888571c74d25c;p=buildroot.git docs/buildroot.html: misc small fixes and strip trailing spaces --- diff --git a/docs/buildroot.html b/docs/buildroot.html index 026791fccf..0862b1beb1 100644 --- a/docs/buildroot.html +++ b/docs/buildroot.html @@ -70,7 +70,7 @@ 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 + working is called the "host system". The compilation toolchain is provided by your distribution, and Buildroot has nothing to do with it.

@@ -173,7 +173,7 @@ 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. + tool. The file is stored in the "binaries/$(PROJECT)/" directory

@@ -181,7 +181,7 @@

Once a package has been unpacked, it is possible to manually update configuration files. Buildroot can automatically save the configuration - of buildroot, linux, busybox, uclibc and u-boot in "local/$(PROJECT) by + of buildroot, linux, busybox, uclibc and u-boot in "local/$(PROJECT) by using the command:

@@ -189,7 +189,7 @@ $ make saveconfig -

Once a buildroot configuration has been created by saveconfig, +

Once a buildroot configuration has been created by saveconfig, the default "$(TOPDIR)/.config" file can be overridden by

@@ -200,7 +200,7 @@
     instead of ".config". 

 
     
If you want to modify your board, you can copy the project configuration
-     file to ".config" by using the command:
 
+     file to ".config" by using the command:

 
 
  $ make BOARD=<project> getconfig
@@ -208,7 +208,7 @@
 
     
You can share your custom board support directory between several buildroot trees
     by setting the environment variable BUILDROOT_LOCAL to this directory,
-    
 
+    

 
 
     

@@ -220,7 +220,7 @@
 
  $ make source
 

-    
You can now disconnect or copy the content of your dl 
+    
You can now disconnect or copy the content of your dl
     directory to the build-host. 

 
     

@@ -298,8 +298,8 @@ $ make me<TAB>
       target filesystem is available under project_build_ARCH/root/
       where ARCH is the chosen target architecture.
       You can simply make your changes here, and run make afterwards, which will
-      rebuild the target filesystem image. This method allows to do everything 
-      on the target filesystem, but if you decide to completely rebuild your 
+      rebuild the target filesystem image. This method allows to do everything
+      on the target filesystem, but if you decide to completely rebuild your
       toolchain and tools, these changes will be lost. 
 
       
  • Customize the target filesystem skeleton, available under
@@ -317,7 +317,7 @@ $ make me<TAB>
       it should be changed. These main directories are in an tarball inside of
       inside the skeleton because it contains symlinks that would be broken
       otherwise. 
    
-      These customizations are deployed into 
+      These customizations are deployed into
       project_build_ARCH/root/ just before the actual image
       is made. So simply rebuilding the image by running
       make should propagate any new changes to the image. 
    • 
@@ -347,10 +347,10 @@ $ make me<TAB>
     
 
     
    Otherwise, you can simply change the
-    package/busybox/busybox-<version>.config file if you 
+    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 
+    
    If you want to use an existing config file for busybox, then see
     section environment variables. 
    
 
     
    Customizing the uClibc
@@ -390,7 +390,7 @@ $ make me<TAB>
     toolchain/uClibc/uClibc.config-locale without running
     the configuration assistant. 
    
 
-    
    If you want to use an existing config file for uclibc, then see 
+    
    If you want to use an existing config file for uclibc, then see
     section environment variables. 
    
 
     
    How Buildroot
@@ -455,24 +455,24 @@ $ make me<TAB>
       
  • 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 
+      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 
+      
  • 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.
       
    • 
 
-      
  • Create the project specific result directory 
-      (binaries/$(PROJECT) by default, where ARCH 
+      
  • Create the project specific result directory
+      (binaries/$(PROJECT) by default, where ARCH
       is your architecture). This is where the root filesystem images are
-      stored, It is also used to store the linux kernel image and any 
+      stored, It is also used to store the linux kernel image and any
       utilities, boot-loaders etc. needed for a target.
       
    • 
 
@@ -512,9 +512,9 @@ $ make me<TAB>
     
    Buildroot has always supported building several projects in the same
     tree if each project was for a different architecture. 
    
 
-    
    The root file system has been created in the 
+    
    The root file system has been created in the
     "build_<ARCH>/root"
-    directory which is unique for each architecture. 
+    directory which is unique for each architecture.
     Toolchains have been built in
     "toolchain_build_<ARCH>". 
    
 
@@ -522,7 +522,7 @@ $ make me<TAB>
     architecture, a prefix or suffix could be added in the configuration file
     so the root file system would be built in
     "<PREFIX>_build_<ARCH>_<SUFFIX>/root"
-    By supplying unique combinations of 
+    By supplying unique combinations of
     "<PREFIX>" and
     "<SUFFIX>"
     each project would get a unique root file system tree. 
    
@@ -531,14 +531,14 @@ $ make me<TAB>
     built for each project,  adding considerable time to the build
     process, even if it was two projects for the same chip. 
    
 
-    
    This drawback has been somewhat lessened with 
-    gcc-4.x.y which allows buildroot to use an external 
+    
    This drawback has been somewhat lessened with
+    gcc-4.x.y which allows buildroot to use an external
     toolchain. Certain packages requires special
     features in the toolchain, and if an external toolchain is selected,
     this may lack the neccessary features to complete the build of the root
      file system.
    
 
-    
    A bigger problem was that the 
+    
    A bigger problem was that the
     "build_<ARCH>" tree
     was also duplicated, so each package would also
     be rebuilt once per project, resulting in even longer build times.
    
@@ -546,29 +546,29 @@ $ make me<TAB>
 
     
    PROJECT TO SHARE TOOLCHAIN AND PACKAGE BUILDS
    
 
-    
    Work has started on a project which will allow the user to build 
-    multiple root file systems for the same architecture in the same tree. 
+    
    Work has started on a project which will allow the user to build
+    multiple root file systems for the same architecture in the same tree.
     The toolchain and the package build directory will be shared, but each
     project will have a dedicated directory tree for project specific
     builds. 
    
 
-    
    With this approach, most, if not all packages will be compiled 
+    
    With this approach, most, if not all packages will be compiled
     when the first project is built.
     The process is almost identical to the original process.
-    Packages are downloaded and extracted to the shared 
+    Packages are downloaded and extracted to the shared
     "build_<ARCH>/<package>"
-    directory. They are configured and compiled. 
     
+    directory. They are configured and compiled. 
    
 
     
    Package libraries and headers are installed in the shared $(STAGING_DIR),
     and then the project specific root file system "$(TARGET_DIR)"
-    is populated. 
     
+    is populated. 
    
 
     
    At the end of the build, the root file system will be used
     to generate the resulting root file system binaries. 
    
 
-    
    Once the first project has been built, building other projects will 
+    
    Once the first project has been built, building other projects will
     typically involve populating the new project's root file system directory
-    from the existing binaries generated in the shared 
+    from the existing binaries generated in the shared
     "build_<ARCH>/<>" directory. 
    
 
     
    Only packages, not used by the first project, will have to go
@@ -585,8 +585,8 @@ $ make me<TAB>
     
  • binaries;
    • 
     
 
-    
    Each of the directories contain one subdirectory per project. 
-    The name of the subdirectory is configured by the user in the 
+    
    Each of the directories contain one subdirectory per project.
+    The name of the subdirectory is configured by the user in the
     normal buildroot configuration, using the value of: 
    
 
     
    Project Options ---> Project name
    
@@ -620,13 +620,13 @@ $ make me<TAB>
     
    will be created. 
    
 
     
    Currently, the root file system, busybox and an Atmel
-    customized version of  
+    customized version of
     U-Boot, as well as some Atmel specific
     bootloaders like at91-bootstrap and dataflashboot.bin
-    are built in 
+    are built in
     "$(PROJECT_BUILD_DIR)"
 
-    
    The resulting binaries for all architectures are stored in the 
+    
    The resulting binaries for all architectures are stored in the
     "$(BINARIES_DIR)" directory. 
    
 
     
    SUMMARY
    
@@ -636,13 +636,13 @@ $ make me<TAB>
     can configure the build. 
    
 
     
    THINGS TO DO
    
-    
+
     
      
 
     
    1. Linux
      2. 
 
     
      The current Linux implementation is flawed. It only works
-    if the user chooses to use one of the few kernels selected 
+    if the user chooses to use one of the few kernels selected
     as base for the kernel-headers. While the Makefile seems to have
     hooks, allowing the developer to specify whatever version he/she
     wants in the target/device/*/* Makefiles, the build will fail
@@ -650,17 +650,17 @@ $ make me<TAB>
 
     
      The reason for this is that the kernel patches are not
     applied by the "target/linux/linux.mk"
-    build script fragment. They are only applied by the 
+    build script fragment. They are only applied by the
     "toolchain/kernel-headers/*.makefile"
     build script fragments
      
 
     
      If the kernel-header version and the linux version differs,
     there will be two "linux-2.6.X.Y"
-    directories in 
+    directories in
     "build_<ARCH>/<>",
     each with its own set of patches. 
      
 
-    
      The solution in the works, is to move the build of Linux to     
+    
      The solution in the works, is to move the build of Linux to
     "project_build_<ARCH>/<project name>/linux-2.6.X.Y" combined with method to configure
      which patches can be applied. Possibly, the linux source tree
      used to generate the kernel headers will be moved to the
@@ -675,18 +675,18 @@ $ make me<TAB>
      
    2. Conservative Strategy: Only use version ssupported by the kernel headers
      3. 
      
    3. Stable Linux Strategy: Allow any 2.6.X.Y combination.
 	(Minimum 2.6.19)
      4. 
-     
    4. Power-User Strategy: Allow 
+     
    5. Power-User Strategy: Allow
      "-git", or
      "-mm", or user downloadable kernels
      6. 
      
 
      
      The current kernel patches can be configured to be applied to the
-     linux source tree even if the version differs from the 
+     linux source tree even if the version differs from the
      kernel header version. 
      
 
      
      Since the user can select any kernel-patch
      he/she will be able to select a non-working combination.
-     If the patch fails, the user will have to generate a new 
+     If the patch fails, the user will have to generate a new
      proprietary kernel-patch or decide to not apply the kernel
      patches
      
 
@@ -696,10 +696,10 @@ $ make me<TAB>
      
      There will also be a way for the user to supply absolute
      or relative paths to patches, possibly outside the main tree.
      This can be used to apply custom kernel-header-patches, if
-     the versions available in buildroot cannot be applied to the 
+     the versions available in buildroot cannot be applied to the
      specific linux version used
      
 
-     
      Maybe, there will also be a possibility to supply an 
+     
      Maybe, there will also be a possibility to supply an
      "URL" to a patch available on Internet. 
      
 
      
    6. Configurable packages
      7. 
@@ -707,12 +707,12 @@ $ make me<TAB>
      
      Many packages can, on top of the simple
      "enable/disable build",
      be further configured using Kconfig.
-     Currently these packages will be compiled using the 
+     Currently these packages will be compiled using the
      configuration specified in the
      ".config" file of the first
      project demanding the build of the package.
      
 
-     
      If another project uses the same packages, but with 
+     
      If another project uses the same packages, but with
      a different configuration,these packages will not be rebuilt,
      and the root file system for the new project will be populated
      with files from the build of the first project
      
@@ -723,8 +723,8 @@ $ make me<TAB>
      "build_<ARCH>" directory
      before rebuilding the new project.
      
 
-     
      A long term solution is to edit the package makefile and move 
-     the build of the configurable packages from 
+     
      A long term solution is to edit the package makefile and move
+     the build of the configurable packages from
      "build_<ARCH>" to
      "project_build_<ARCH>/<project name>"
      and send a patch to the buildroot mailing list.
@@ -737,16 +737,16 @@ $ make me<TAB>
      
    7. Generating File System binaries
      8. 
      
      
      Packages which needs to be installed with the "root"
-     as owner, will generate a 
+     as owner, will generate a
      ".fakeroot.<package>" file
      which will be used for the final build of the root file system binary. 
      
 
-     
      This was previously located in the 
+     
      This was previously located in the
      "$(STAGING_DIR)" directory, but was
-     recently moved to the 
+     recently moved to the
      "$(PROJECT_BUILD_DIR)" directory. 
      
 
-     
      Currently only three packages: 
+     
      Currently only three packages:
      "at",
      "ltp-testsuite" and
      "nfs-utils"
@@ -764,7 +764,7 @@ $ make me<TAB>
      ".fakeroot.<package>"
      files are deleted as the last action of the Buildroot Makefile. 
      
 
-     
      It needs to be evaluated if any further action for the 
+     
      It needs to be evaluated if any further action for the
      file system binary build is needed. 
      
 
      
    
@@ -816,7 +816,7 @@ mips-linux-gcc -o foo foo.c
     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 there
-    are some hardcoded paths in the toolchain configuration. This works, thanks 
+    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,
@@ -850,7 +850,7 @@ ln -s <shared download location> dl
     
    Another way of accessing a shared download location is to
     create the BUILDROOT_DL_DIR environment variable.
     If this is set, then the value of DL_DIR in the project is
-    overridden. The following line should be added to 
+    overridden. The following line should be added to
     "~/.bashrc". 
    
 
 
    @@ -911,10 +911,10 @@ endif
    
    Two types of Makefiles can be written :
    
 
    
      
-    
    • Makefile for autotools-based (autoconf, automake, etc.)
+    
    • Makefiles for autotools-based (autoconf, automake, etc.)
     softwares, are very easy to write thanks to the infrastructure
     available in package/Makefile.autotools.in.
      • 
-    
    • Makefile for other types of packages are a little bit more
+    
    • Makefiles for other types of packages are a little bit more
     complex to write.
      • 
    
    
 
@@ -1048,7 +1048,7 @@ endif
     the other *.mk files in the package
     directory. 
    
 
-    
    At lines 6-11, a couple of useful variables are 
+    
    At lines 6-11, a couple of useful variables are
     defined :
    
 
     
      
@@ -1078,21 +1078,21 @@ endif
 
     
    
 
-    
    Lines 13-14 defines a target that downloads the 
+    
    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 
+    
    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 
+    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 
+    
    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
@@ -1104,14 +1104,14 @@ endif
     filesystem. Finally it creates a .configured file to
     mark the software as configured. 
    
 
-    
    Lines 33-34 defines a target and a rule that 
+    
    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 
+    
    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
@@ -1122,7 +1122,7 @@ endif
     /usr/man directory inside the target filesystem is
     removed to save space. 
    
 
-    
    Line 40 defines the main target of the software, 
+    
    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
@@ -1131,33 +1131,33 @@ endif
     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 
+    
    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 
+    
    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 
+    
    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 
+    
    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, 
+    line 40, which is used by Buildroot to download,
     compile, and then install this package.