There is basically one Makefile per software, and they are named with
- the .mk extension. Makefiles are split into three
+ the .mk extension. Makefiles are split into four
sections:
package/ directory) contains the
- Makefiles and associated files for all user-space tools that Buildroot
- can compile and add to the target root filesystem. There is one
- sub-directory per tool. project/ directory) contains
+ the Makefiles and associated files for all software related to the
+ building several root file systems in the same buildroot tree. toolchain/ directory) contains
the Makefiles and associated files for all software related to the
@@ -360,6 +359,11 @@ $ make me<TAB>
gcc, gdb, kernel-headers and
uClibc. package/ directory) contains the
+ Makefiles and associated files for all user-space tools that Buildroot
+ can compile and add to the target root filesystem. There is one
+ sub-directory per tool. target directory) contains the
Makefiles and associated files for software related to the generation of
the target root filesystem image. Four types of filesystems are supported
@@ -442,6 +446,271 @@ $ make me<TAB>
TARGETS global variable. BACKGROUND
+ +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
+ "build_<ARCH>/root"
+ directory which is unique for each architecture.
+ Toolchains have been built in
+ "toolchain_build_<ARCH>".
It the user wanted to build several root file systems for the same
+ 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
+ "<PREFIX>" and
+ "<SUFFIX>"
+ each project would get a unique root file system tree.
The disadvantage of this approach is that a new toolchain was + 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
+ 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
+ "build_<ARCH>" tree
+ was also duplicated, so each package would also
+ be rebuilt once per project, resulting in even longer build times.
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. + 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
+ when the first project is built.
+ The process is almost identical to the original process.
+ Packages are downloaded and extracted to the shared
+ "build_<ARCH>/<package>"
+ 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.
+ +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
+ typically involve populating the new project's root file system directory
+ from the existing binaries generated in the shared
+ "build_<ARCH>/<>" directory.
Only packages, not used by the first project, will have to go + through the normal extract-configure-compile flow.
+ +IMPLEMENTATION
+ +The core of the solution is the introduction + of two new directories:
+ +project_build_<ARCH>binaries;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
The configuration defines the $(PROJECT) variable.
+ +The default project name is "uclibc".
"package/Makefile.in" defines:
+
++ + +PROJECT_BUILD_DIR:=project_build_$(ARCH)/$(PROJECT)+BINARIES_DIR:=binaries/$(PROJECT)+
It also defines the location for the target root file system: +
+ TARGET_DIR:=$(PROJECT_BUILD_DIR)/$(PROJECT)/root
+
+
+
+ I.E: If the user has choosen
+ "myproject"
+ as the $(PROJECT) name:
+
+
"project_build_<ARCH>/myproject""binaries/myproject"will be created.
+ +Currently, the root file system, busybox and an Atmel
+ customized version of
+ U-Boot, as well as some Atmel specific
+ bootloaders like at91-bootstrap and dataflashboot.bin
+ are built in
+ "$(PROJECT_BUILD_DIR)"
+
+
The resulting binaries for all architectures are stored in the
+ "$(BINARIES_DIR)" directory.
+ +
SUMMARY
+ +The project will share directories which can be share without + conflicts, but will use unique build directories, where the user + can configure the build.
+ +THINGS TO DO
+ +The current Linux implementation is flawed. It only works + 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 + if another kernel version is choosen.
+ +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
+ "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
+ "build_<ARCH>/<>",
+ each with its own set of patches.
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
+ "toolchain_build_<ARCH>"
+ directory
+
The user will be able to select from three different + Linux strategies: + +
"-git", or
+ "-mm", or user downloadable kernelsThe current kernel patches can be configured to be applied to 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 + proprietary kernel-patch or decide to not apply the kernel + patches
+ +Other optional patches will be board specific or + architecture specific patches.
+ +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 + specific linux version used
+ +Maybe, there will also be a possibility to supply an
+ "URL" to a patch available on Internet.
Many packages can, on top of the simple
+ "enable/disable build",
+ be further configured using Kconfig.
+ 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 + 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
+ +If multiple project are built, and a specific package
+ needs two different configuration, then the user must
+ delete the package from the
+ "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
+ "build_<ARCH>" to
+ "project_build_<ARCH>/<project name>"
+ and send a patch to the buildroot mailing list.
+
+
Names of resulting binaries should reflect the + "project name" + +
+ Packages which needs to be installed with the "root"
+ 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
+ "$(STAGING_DIR)" directory, but was
+ recently moved to the
+ "$(PROJECT_BUILD_DIR)" directory.
Currently only three packages:
+ "at",
+ "ltp-testsuite" and
+ "nfs-utils"
+ requests fakeroot.
+ +
The makefile fragments for each file system type like
+ "ext2",
+ "jffs2" or
+ "squashfs"
+ will, when the file system binary is generated,
+ collect all present
+ ".fakeroot.<package>" files
+ to a single "_fakeroot.<file system>"
+ file and call fakeroot.
".fakeroot.<package>"
+ files are deleted as the last action of the Buildroot Makefile.
+
+ It needs to be evaluated if any further action for the + file system binary build is needed.
+ +