All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.