gitolite/buildrootschalter
gitolite/buildrootschalter
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

manual: misc. post-{build, image} scripts fixes

Browse Source 
* update post-build scripts mechanism that now support several scripts
* fix formatting

Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
This commit is contained in:
Samuel Martin 2013-02-25 11:31:23 +00:00 committed by Peter Korsgaard
parent 7a26f2f663
commit 0ccfbb5db9
1 changed files with 16 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
docs/manual/customize-rootfs.txt
View File

@ -25,18 +25,18 @@ there are a few ways to customize the resulting target filesystem.
directories, +.empty+ files and files ending with +~+ are excluded. directories, +.empty+ files and files ending with +~+ are excluded.
_Among these first 3 methods, this one should be preferred_. _Among these first 3 methods, this one should be preferred_.
* In the Buildroot configuration, you can specify the path to a * In the Buildroot configuration, you can specify the paths to one or
*post-build script*, that gets called 'after' Buildroot builds all the more *post-build scripts*. These scripts are called in the given order,
selected software, but 'before' the rootfs packages are 'after' Buildroot builds all the selected software, but 'before' the
assembled. The +BR2_ROOTFS_POST_BUILD_SCRIPT+ will allow you to rootfs images are assembled. The +BR2_ROOTFS_POST_BUILD_SCRIPT+ allows
specify the location of your post-build script. This option can be you to specify the location of your post-build scripts. This option can be
found in the +System configuration+ menu. The destination root found in the +System configuration+ menu. The destination root
filesystem folder is given as the first argument to this script, filesystem folder is given as the first argument to these scripts,
and this script can then be used to remove or modify any file in your 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. target filesystem. You should, however, use this feature with care.
Whenever you find that a certain package generates wrong or unneeded Whenever you find that a certain package generates wrong or unneeded
files, you should fix that package rather than work around it with a files, you should fix that package rather than work around it with some
post-build cleanup script. post-build cleanup scripts.
You may also use these variables in your post-build script: You may also use these variables in your post-build script:
- +BUILDROOT_CONFIG+: the path to the Buildroot .config file - +BUILDROOT_CONFIG+: the path to the Buildroot .config file
- +HOST_DIR+, +STAGING_DIR+, +TARGET_DIR+: see - +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 installation. Note that this method is *not recommended*, as it
duplicates the entire skeleton, which prevents from taking advantage duplicates the entire skeleton, which prevents from taking advantage
of the fixes or improvements brought to the default Buildroot 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. mechanism described in the previous item.
Note also that if you want to perform some specific actions *after* Note also that you can use the *post-image scripts*
all filesystem images have been created (for example to automatically if you want to perform some specific actions 'after' all
filesystem images have been created (for example to automatically
extract your root filesystem tarball in a location exported by your extract your root filesystem tarball in a location exported by your
NFS server, or to create a special firmware image that bundles 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 root filesystem and kernel image, or any other custom action), you can
specify a space-separated list of scripts in the 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+ Each of those scripts will be called with the path to the +images+
output directory as first and unique argument, and will be executed output directory as first and unique argument, and will be executed
with the main Buildroot source directory as the current with the main Buildroot source directory as the current
directory. Those scripts will be executed as the user that executes directory. Those scripts will be executed as the user that executes
Buildroot, which should normally not be the root user. Therefore, any 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 will require special handling (usage of fakeroot or sudo), which is
left to the script developer. left to the script developer.