Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 7/9] manual: misc. post-{build, image} scripts fixes
Date: Thu, 14 Feb 2013 08:16:04 +0100	[thread overview]
Message-ID: <511C8F34.9010207@mind.be> (raw)
In-Reply-To: <76731c24e8bd3e8099cc5f5ef54ad918b1770e32.1360795941.git.s.martin49@gmail.com>

On 13/02/13 23:59, Samuel Martin wrote:
> * update post-build scripts mechanism that now support several scripts
> * fix formatting
> 
> Signed-off-by: Samuel Martin <s.martin49@gmail.com>
> ---
>   docs/manual/customize-rootfs.txt | 30 ++++++++++++++++--------------
>   1 file changed, 16 insertions(+), 14 deletions(-)
> 
> diff --git a/docs/manual/customize-rootfs.txt b/docs/manual/customize-rootfs.txt
> index 4a4d620..95dfc16 100644
> --- a/docs/manual/customize-rootfs.txt
> +++ b/docs/manual/customize-rootfs.txt
> @@ -25,18 +25,18 @@ there are a few ways to customize the resulting target filesystem.
>     directories, +.empty+ files and files ending with +~+ are excluded.
>     _Among these first 3 methods, this one should be preferred_.
>   
> -* In the Buildroot configuration, you can specify the path to a
> -  *post-build script*, that gets called 'after' Buildroot builds all the
> -  selected software, but 'before' the rootfs packages are
> -  assembled. The +BR2_ROOTFS_POST_BUILD_SCRIPT+ will allow you to
> -  specify the location of your post-build script. This option can be
> +* In the Buildroot configuration, you can specify the pathes to a
> +  *post-build scripts*, that get called in order, *after* _Buildroot builds
> +  all the selected software_, but *before* _the rootfs packages are
> +  assembled_. The +BR2_ROOTFS_POST_BUILD_SCRIPT+ will allow you to
> +  specify the location of your post-build scripts. This option can be

 Several remarks:

- pathes -> paths
- plural doesn't have 'a'
- bold should be used very sparsely
- don't see a reason to emphasize the Buildroot builds... clause.

 Alternative:

* In the Buildroot configuration, you can specify the paths to one or 
  more *post-build scripts*. These scripts are called in the given order,
  'after' Buildroot builds all the selected software, but 'before' the
  rootfs images are assembled. The +BR2_ROOTFS_POST_BUILD_SCRIPT+ allows
  you to specify the location of your post-build scripts. This option can be


>     found in the +System configuration+ menu. The destination root
> -  filesystem folder is given as the first argument to this script,
> -  and this script can then be used to remove or modify any file in your
> +  filesystem folder is given as the first argument to these scripts,
> +  and these scripts can then be used to remove or modify any file in your
>     target filesystem. You should, however, use this feature with care.
>     Whenever you find that a certain package generates wrong or unneeded
> -  files, you should fix that package rather than work around it with a
> -  post-build cleanup script.
> +  files, you should fix that package rather than work around it with some
> +  post-build cleanup scripts.
>     You may also use these variables in your post-build script:
>       - +BUILDROOT_CONFIG+: the path to the Buildroot .config file
>       - +HOST_DIR+, +STAGING_DIR+, +TARGET_DIR+: see
> @@ -55,23 +55,25 @@ there are a few ways to customize the resulting target filesystem.
>     installation. Note that this method is *not recommended*, as it
>     duplicates the entire skeleton, which prevents from taking advantage
>     of the fixes or improvements brought to the default Buildroot
> -  skeleton. The recommended method is to use the _post-build script_
> +  skeleton. The recommended method is to use the _post-build scripts_
>     mechanism described in the previous item.
>   
> -Note also that if you want to perform some specific actions *after*
> -all filesystem images have been created (for example to automatically
> +Note also that you can use the *post-image scripts*
> +if you want to perform some specific actions *after* _all
> +filesystem images have been created_ (for example to automatically

 Same remark about emphasis.

 Regards,
 Arnout

>   extract your root filesystem tarball in a location exported by your
>   NFS server, or to create a special firmware image that bundles your
>   root filesystem and kernel image, or any other custom action), you can
>   specify a space-separated list of scripts in the
> -+BR2_ROOTFS_POST_IMAGE_SCRIPT+ configuration option.
> ++BR2_ROOTFS_POST_IMAGE_SCRIPT+ configuration option. This option can be
> +found in the +System configuration+ menu as well.
>   
>   Each of those scripts will be called with the path to the +images+
>   output directory as first and unique argument, and will be executed
>   with the main Buildroot source directory as the current
>   directory. Those scripts will be executed as the user that executes
>   Buildroot, which should normally not be the root user. Therefore, any
> -action requiring root permissions in one of these post-image script
> +action requiring root permissions in one of these _post-image scripts_
>   will require special handling (usage of fakeroot or sudo), which is
>   left to the script developer.
>   
> 


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

  reply	other threads:[~2013-02-14  7:16 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-13 22:59 [Buildroot] [pull request] Pull request for branch for-master/doc Samuel Martin
2013-02-13 22:59 ` [Buildroot] [PATCH 1/9] manual: cleanup and update editor tags Samuel Martin
2013-02-14  6:47   ` Arnout Vandecappelle
2013-02-17 21:50   ` Peter Korsgaard
2013-02-13 22:59 ` [Buildroot] [PATCH 2/9] manual: fix cross-refs Samuel Martin
2013-02-14  6:46   ` Arnout Vandecappelle
2013-02-13 22:59 ` [Buildroot] [PATCH 3/9] manual: sprinkle with some calls to MESSAGE Samuel Martin
2013-02-14  6:48   ` Arnout Vandecappelle
2013-02-17 21:51   ` Peter Korsgaard
2013-02-13 22:59 ` [Buildroot] [PATCH 4/9] manual: faq: add entry about the relocatable toolchain Samuel Martin
2013-02-14  6:49   ` Arnout Vandecappelle
2013-02-14 17:32   ` Thomas Petazzoni
2013-02-23 13:33     ` Samuel Martin
2013-02-13 22:59 ` [Buildroot] [PATCH 5/9] manual: faq: add workaround to avoid rebuilding the buildroot toolchain after each clean Samuel Martin
2013-02-14  7:04   ` Arnout Vandecappelle
2013-02-14 17:36   ` Thomas Petazzoni
2013-02-23 13:34     ` Samuel Martin
2013-02-13 22:59 ` [Buildroot] [PATCH 6/9] manual: minor fix in patch-policy.txt Samuel Martin
2013-02-14  7:06   ` Arnout Vandecappelle
2013-02-14 17:37   ` Thomas Petazzoni
2013-02-17 21:54   ` Peter Korsgaard
2013-02-13 22:59 ` [Buildroot] [PATCH 7/9] manual: misc. post-{build, image} scripts fixes Samuel Martin
2013-02-14  7:16   ` Arnout Vandecappelle [this message]
2013-02-13 22:59 ` [Buildroot] [PATCH 8/9] manual: update {deprecated, package}-list.txt Samuel Martin
2013-02-18  7:23   ` Arnout Vandecappelle
2013-02-25 21:22     ` Samuel Martin
2013-02-13 22:59 ` [Buildroot] [PATCH 9/9] Makefile: add to the release target a warning about the manual updates Samuel Martin

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=511C8F34.9010207@mind.be \
    --to=arnout@mind.be \
    --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