From: Thomas De Schampheleire <patrickdepinguin@gmail.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 13 of 13] manual/user guide/customization: add section on layered customization
Date: Thu, 18 Sep 2014 21:39:36 +0200 [thread overview]
Message-ID: <725a43220424c4bcdfd8.1411069176@localhost> (raw)
In-Reply-To: <patchbomb.1411069163@localhost>
Inspired by some text in the 'project-specific patches' section, this patch
adds a separate section on layering customizations by providing multiple
post-build scripts, multiple rootfs overlays, etc.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
---
docs/manual/customize-directory-structure.txt | 51 +++++++++++++++++++
docs/manual/customize-patches.txt | 40 +--------------
2 files changed, 52 insertions(+), 39 deletions(-)
diff --git a/docs/manual/customize-directory-structure.txt b/docs/manual/customize-directory-structure.txt
--- a/docs/manual/customize-directory-structure.txt
+++ b/docs/manual/customize-directory-structure.txt
@@ -56,3 +56,54 @@
Note: if you choose to place this structure outside of the Buildroot
tree using +BR2_EXTERNAL+, the <company> and possibly <boardname>
components may be superfluous and can be left out.
+
+==== Implementing layered customizations
+
+It is quite common for a user to have several related projects that partly
+need the same customizations. Instead of duplicating these
+customizations for each project, it is recommended to use a layered
+customization approach, as explained in this section.
+
+Almost all of the customization methods available in Buildroot, like
+post-build scripts and root filesystem overlays, accept a
+space-separated list of items. The specified items are always treated in
+order, from left to right. By creating more than one such item, one for
+the common customizations and another one for the really
+project-specific customizations, you can avoid unnecessary duplication.
+Each layer is typically embodied by a separate directory inside
++board/<company>/+. Depending on your projects, you could even introduce
+more than two layers.
+
+An example directory structure for where a user has two customization
+layers 'common' and 'fooboard' is:
+
+-----
++-- board/
+ +-- <company>/
+ +-- common/
+ | +-- post_build.sh
+ | +-- rootfs_overlay/
+ | | +-- ...
+ | +-- patches/
+ | +-- ...
+ |
+ +-- fooboard/
+ +-- linux.config
+ +-- busybox.config
+ +-- <other configuration files>
+ +-- post_build.sh
+ +-- rootfs_overlay/
+ | +-- ...
+ +-- patches/
+ +-- ...
+-----
+
+For example, if the user has the +BR2_GLOBAL_PATCH_DIR+ configuration
+option set as:
+
+-----
+BR2_GLOBAL_PATCH_DIR="board/<company>/common/patches board/<company>/fooboard/patches"
+-----
+
+then first the patches from the 'common' layer would be applied,
+followed by the patches from the 'fooboard' layer.
diff --git a/docs/manual/customize-patches.txt b/docs/manual/customize-patches.txt
--- a/docs/manual/customize-patches.txt
+++ b/docs/manual/customize-patches.txt
@@ -10,13 +10,7 @@
The +BR2_GLOBAL_PATCH_DIR+ configuration option can be used to specify
a space separated list of one or more directories containing package
-patches. By specifying multiple global patch directories, a user could
-implement a layered approach to patches. This could be useful when a
-user has multiple boards that share a common processor architecture.
-It is often the case that a subset of patches for a package need to be
-shared between the different boards a user has. However, each board
-may require specific patches for the package that build on top of the
-common subset of patches.
+patches.
For a specific version +<packageversion>+ of a specific package
+<packagename>+, patches are applied from +BR2_GLOBAL_PATCH_DIR+ as
@@ -63,35 +57,3 @@
patches that are applied after patches available in +BR2_GLOBAL_PATCH_DIR+,
as it is done from a post-patch hook of the Linux package.
-An example directory structure for where a user has multiple
-directories specified for +BR2_GLOBAL_PATCH_DIR+ may look like this:
-
------
-board/
-+-- common-fooarch
-| +-- patches
-| +-- linux
-| | +-- linux-patch1.patch
-| | +-- linux-patch2.patch
-| +-- uboot
-| +-- foopkg
-+-- fooarch-board
- +-- patches
- +-- linux
- | +-- linux-patch3.patch
- +-- uboot
- +-- foopkg
------
-
-If the user has the +BR2_GLOBAL_PATCH_DIR+ configuration option set as
-follows:
-
------
-BR2_GLOBAL_PATCH_DIR="board/common-fooarch/patches board/fooarch-board/patches"
------
-
-Then the patches would applied as follows for the Linux kernel:
-
-. board/common-fooarch/patches/linux/linux-patch1.patch
-. board/common-fooarch/patches/linux/linux-patch2.patch
-. board/fooarch-board/patches/linux/linux-patch3.patch
next prev parent reply other threads:[~2014-09-18 19:39 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-18 19:39 [Buildroot] [PATCH 00 of 13] manual: improvements in 'Project-specific customization' section Thomas De Schampheleire
2014-09-18 19:39 ` [Buildroot] [PATCH 01 of 13] manual: move 'Creating your own board support' from User to Developer guide Thomas De Schampheleire
2014-09-18 19:39 ` [Buildroot] [PATCH 02 of 13] manual/developer guide: minor rework of 'adding board support' section Thomas De Schampheleire
2014-09-18 19:39 ` [Buildroot] [PATCH 03 of 13] manual/user guide/customization: move section on storing configuration Thomas De Schampheleire
2014-09-18 19:39 ` [Buildroot] [PATCH 04 of 13] manual/user guide/customization: rework " Thomas De Schampheleire
2014-09-18 19:39 ` [Buildroot] [PATCH 05 of 13] manual/user guide/customization: re-order introduction Thomas De Schampheleire
2014-09-18 19:39 ` [Buildroot] [PATCH 06 of 13] manual/user guide/customization: add section on device/permission tables Thomas De Schampheleire
2014-09-18 19:39 ` [Buildroot] [PATCH 07 of 13] manual/user guide/customization: add section on users tables Thomas De Schampheleire
2014-09-18 19:39 ` [Buildroot] [PATCH 08 of 13] manual/user guide/customization: rename section 'Customizing packages' Thomas De Schampheleire
2014-09-18 19:39 ` [Buildroot] [PATCH 09 of 13] manual/user guide/customization: change recommendation for package paths Thomas De Schampheleire
2014-09-18 19:39 ` [Buildroot] [PATCH 10 of 13] manual/user guide/customization: add section on project-specific packages Thomas De Schampheleire
2014-09-18 19:39 ` [Buildroot] [PATCH 11 of 13] manual/user guide/customization: refer to dir structure from rootfs section Thomas De Schampheleire
2014-09-18 19:39 ` [Buildroot] [PATCH 12 of 13] manual/user guide/customization: rework 'step-by-step instructions' Thomas De Schampheleire
2014-09-18 19:39 ` Thomas De Schampheleire [this message]
2014-09-18 20:03 ` [Buildroot] [PATCH 00 of 13] manual: improvements in 'Project-specific customization' section Thomas Petazzoni
2014-09-19 6:40 ` Thomas De Schampheleire
2014-09-21 17:42 ` Thomas Petazzoni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=725a43220424c4bcdfd8.1411069176@localhost \
--to=patrickdepinguin@gmail.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox