| Message ID | 20121013231448.17317.37653.stgit@localhost |
|---|---|
| State | RFC |
| Headers | show |
Arnout, On Sat, Oct 13, 2012 at 7:14 PM, Arnout Vandecappelle (Essensium/Mind) < arnout@mind.be> wrote: > The filesystem overlay is a tree that is copied over the target fs > after building everything - which is currently usually done in the > post-build script. > I'm very happy to see the overlay fs concept get introduced. We introduced an almost identical concept to our customized buildroot a couple of years ago, and found it to be a great addition. In particular, it lets us keep a full skeleton with most of our files, and a couple very small overlays for things that we want just in an NFS-mount dev scenario and just in a FLASH image scenario. However, we still make use of the custom target skeleton feature. Basically, we wanted to keep our initial skeleton in our project directory with our overlays, rather than hack up the default skeleton that comes with buildroot. Also, we wanted to avoid having to maintain a list of files installed by the default skeleton that then need to be deleted in a post-build script. (The truth is that we use our custom skeleton both as the initial custom skeleton that gets copied during the beginning of the process, and as an overlay that gets copied at the end of the process, so that no package-installed scripts take precedence over our customized target skeleton files.) So I still see use, at least for us, for a custom skeleton. No? Danomi -
On 14/10/12 02:39, Danomi Manchego wrote: > However, we still make use of the custom target skeleton feature. Basically, we wanted to keep our initial skeleton in > our project directory with our overlays, rather than hack up the default skeleton that comes with buildroot. Also, we > wanted to avoid having to maintain a list of files installed by the default skeleton that then need to be deleted in a > post-build script. > > (The truth is that we use our custom skeleton both as the initial custom skeleton that gets copied during the beginning > of the process, and as an overlay that gets copied at the end of the process, so that no package-installed scripts > take precedence over our customized target skeleton files.) > > So I still see use, at least for us, for a custom skeleton. No? If you need to remove files from the default skeleton, then there's something wrong with the default skeleton. Now I take a second look, indeed there's a lot in there that is unneeded, e.g. .bash_profile if no bash is installed... So I'll un-deprecate the custom skeleton in the next round. Regards, Arnout
On Sun, Oct 14, 2012 at 8:53 AM, Arnout Vandecappelle <arnout@mind.be>wrote: > On 14/10/12 02:39, Danomi Manchego wrote: > >> However, we still make use of the custom target skeleton feature. >> Basically, we wanted to keep our initial skeleton in >> our project directory with our overlays, rather than hack up the default >> skeleton that comes with buildroot. Also, we >> wanted to avoid having to maintain a list of files installed by the >> default skeleton that then need to be deleted in a >> post-build script. >> >> (The truth is that we use our custom skeleton both as the initial custom >> skeleton that gets copied during the beginning >> of the process, and as an overlay that gets copied at the end of the >> process, so that no package-installed scripts >> take precedence over our customized target skeleton files.) >> >> So I still see use, at least for us, for a custom skeleton. No? >> > > If you need to remove files from the default skeleton, then there's > something > wrong with the default skeleton. Now I take a second look, indeed there's > a lot > in there that is unneeded, e.g. .bash_profile if no bash is installed... > Maybe saying that the files "need to be deleted" was too strong. I didn't really distinguish between "need to be deleted" versus "files that are unneeded and potentially confusing to others by their presence". Anyway, thanks for agreeing to un-deprecate. Danomi - > > So I'll un-deprecate the custom skeleton in the next round. > > Regards, > Arnout > > -- > Arnout Vandecappelle arnout at mind be > Senior Embedded Software Architect +32-16-286540 > 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<http://www.linkedin.com/in/arnoutvandecappelle> > GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F >
On Sun, Oct 14, 2012 at 1:14 AM, Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> wrote: > From: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> > > The filesystem overlay is a tree that is copied over the target fs > after building everything - which is currently usually done in the > post-build script. > > Also replace the documentation for a custom skeleton with the > filesystem overlay and deprecate the custom skeleton. > > Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Note that I'm not against this feature, but we discussed this before (I think on Buildroot Developer Day in Brussels beginning of 2012, or otherwise on the list) and the outcome back then was that it was not necessary as it was very easy to add directly to the post-build script. > --- > Makefile | 9 +++++++++ > docs/manual/customize-rootfs.txt | 21 +++++++++------------ > target/generic/Config.in | 13 +++++++++++++ > 3 files changed, 31 insertions(+), 12 deletions(-) > > diff --git a/Makefile b/Makefile > index a3b88f7..31770ce 100644 > --- a/Makefile > +++ b/Makefile > @@ -466,6 +466,15 @@ endif > echo "PRETTY_NAME=\"Buildroot $(BR2_VERSION)\"" \ > ) > $(TARGET_DIR)/etc/os-release > > + @for dir in $(call qstrip,$(BR2_ROOTFS_OVERLAY)); do \ > + if [ -d $${dir} ]; then \ > + $(call MESSAGE,"Copying overlay $${dir}"); \ > + rsync -a \ > + --exclude .svn --exclude .git --exclude .hg --exclude '*~' \ > + $${dir}/ $(TARGET_DIR); \ > + fi \ > + done > + > ifneq ($(BR2_ROOTFS_POST_BUILD_SCRIPT),"") > @$(call MESSAGE,"Executing post-build script") > $(BR2_ROOTFS_POST_BUILD_SCRIPT) $(TARGET_DIR) > diff --git a/docs/manual/customize-rootfs.txt b/docs/manual/customize-rootfs.txt > index 8c3ea82..b3c160b 100644 > --- a/docs/manual/customize-rootfs.txt > +++ b/docs/manual/customize-rootfs.txt > @@ -1,5 +1,6 @@ > Customizing the generated target filesystem > ------------------------------------------- > +[customize-rootfs] > > There are a few ways to customize the resulting target filesystem: > > @@ -10,24 +11,20 @@ There are a few ways to customize the resulting target filesystem: > anything to the target filesystem, but if you decide to completely > rebuild your toolchain and tools, these changes will be lost. > > -* Create your own 'target skeleton'. You can start with the default > - skeleton available under +fs/skeleton+ and then customize it to suit > - your needs. The +BR2_ROOTFS_SKELETON_CUSTOM+ and > - +BR2_ROOTFS_SKELETON_CUSTOM_PATH+ will allow you to specify the > - location of your custom skeleton. At build time, the contents of the > - skeleton are copied to output/target before any package > - installation. > +* Create a filesystem overlay: a tree of files that are copied directly > + over the target filesystem after it has been built. Set > + +BR2_ROOTFS_OVERLAY+ to the top of the tree. +.git+, +.svn+, > + +.hg+ directories and files ending with +~+ are excluded. > > * 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 destination root filesystem folder is given as the > first argument to this script, and this script can then be used to > - copy programs, static data or any other needed file to 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. > + 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. > > * A special package, 'customize', stored in +package/customize+ can be > used. You can put all the files that you want to see in the final > diff --git a/target/generic/Config.in b/target/generic/Config.in > index 76137b7..35cadfb 100644 > --- a/target/generic/Config.in > +++ b/target/generic/Config.in > @@ -105,6 +105,7 @@ config BR2_ROOTFS_SKELETON_DEFAULT > > config BR2_ROOTFS_SKELETON_CUSTOM > bool "custom target skeleton" > + depends on BR2_DEPRECATED > help > Use custom target skeleton. > > @@ -168,6 +169,18 @@ config BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW > > endif # BR2_ROOTFS_SKELETON_DEFAULT > > +config BR2_ROOTFS_OVERLAY > + string "Root filesystem overlay" > + default "$(PROJECT_DIR)/rootfs-overlay" if BR2_PROJECT_DIR != "" > + default "" > + help > + Specify a list of directories that are copied over the target > + root filesystem after the build has finished and before it is > + packed into the selected filesystem images. > + > + It is copied as-is into the rootfs, excluding files ending with > + ~ and .git, .svn and .hg directories. > + > config BR2_ROOTFS_POST_BUILD_SCRIPT > string "Custom script to run before creating filesystem images" > default "$(PROJECT_DIR)/post-build.sh" if BR2_PROJECT_DIR != "" > > _______________________________________________ > buildroot mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot
On 14/10/12 20:50, Thomas De Schampheleire wrote: > On Sun, Oct 14, 2012 at 1:14 AM, Arnout Vandecappelle (Essensium/Mind) > <arnout@mind.be> wrote: >> > From: Arnout Vandecappelle (Essensium/Mind)<arnout@mind.be> >> > >> > The filesystem overlay is a tree that is copied over the target fs >> > after building everything - which is currently usually done in the >> > post-build script. >> > >> > Also replace the documentation for a custom skeleton with the >> > filesystem overlay and deprecate the custom skeleton. >> > >> > Signed-off-by: Arnout Vandecappelle (Essensium/Mind)<arnout@mind.be> > Note that I'm not against this feature, but we discussed this before > (I think on Buildroot Developer Day in Brussels beginning of 2012, or > otherwise on the list) and the outcome back then was that it was not > necessary as it was very easy to add directly to the post-build > script. I understood it as: it's a low-priority nice-to-have because there are other ways to do it. So I will resend this patch. Regards, Arnout
diff --git a/Makefile b/Makefile index a3b88f7..31770ce 100644 --- a/Makefile +++ b/Makefile @@ -466,6 +466,15 @@ endif echo "PRETTY_NAME=\"Buildroot $(BR2_VERSION)\"" \ ) > $(TARGET_DIR)/etc/os-release + @for dir in $(call qstrip,$(BR2_ROOTFS_OVERLAY)); do \ + if [ -d $${dir} ]; then \ + $(call MESSAGE,"Copying overlay $${dir}"); \ + rsync -a \ + --exclude .svn --exclude .git --exclude .hg --exclude '*~' \ + $${dir}/ $(TARGET_DIR); \ + fi \ + done + ifneq ($(BR2_ROOTFS_POST_BUILD_SCRIPT),"") @$(call MESSAGE,"Executing post-build script") $(BR2_ROOTFS_POST_BUILD_SCRIPT) $(TARGET_DIR) diff --git a/docs/manual/customize-rootfs.txt b/docs/manual/customize-rootfs.txt index 8c3ea82..b3c160b 100644 --- a/docs/manual/customize-rootfs.txt +++ b/docs/manual/customize-rootfs.txt @@ -1,5 +1,6 @@ Customizing the generated target filesystem ------------------------------------------- +[customize-rootfs] There are a few ways to customize the resulting target filesystem: @@ -10,24 +11,20 @@ There are a few ways to customize the resulting target filesystem: anything to the target filesystem, but if you decide to completely rebuild your toolchain and tools, these changes will be lost. -* Create your own 'target skeleton'. You can start with the default - skeleton available under +fs/skeleton+ and then customize it to suit - your needs. The +BR2_ROOTFS_SKELETON_CUSTOM+ and - +BR2_ROOTFS_SKELETON_CUSTOM_PATH+ will allow you to specify the - location of your custom skeleton. At build time, the contents of the - skeleton are copied to output/target before any package - installation. +* Create a filesystem overlay: a tree of files that are copied directly + over the target filesystem after it has been built. Set + +BR2_ROOTFS_OVERLAY+ to the top of the tree. +.git+, +.svn+, + +.hg+ directories and files ending with +~+ are excluded. * 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 destination root filesystem folder is given as the first argument to this script, and this script can then be used to - copy programs, static data or any other needed file to 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. + 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. * A special package, 'customize', stored in +package/customize+ can be used. You can put all the files that you want to see in the final diff --git a/target/generic/Config.in b/target/generic/Config.in index 76137b7..35cadfb 100644 --- a/target/generic/Config.in +++ b/target/generic/Config.in @@ -105,6 +105,7 @@ config BR2_ROOTFS_SKELETON_DEFAULT config BR2_ROOTFS_SKELETON_CUSTOM bool "custom target skeleton" + depends on BR2_DEPRECATED help Use custom target skeleton. @@ -168,6 +169,18 @@ config BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW endif # BR2_ROOTFS_SKELETON_DEFAULT +config BR2_ROOTFS_OVERLAY + string "Root filesystem overlay" + default "$(PROJECT_DIR)/rootfs-overlay" if BR2_PROJECT_DIR != "" + default "" + help + Specify a list of directories that are copied over the target + root filesystem after the build has finished and before it is + packed into the selected filesystem images. + + It is copied as-is into the rootfs, excluding files ending with + ~ and .git, .svn and .hg directories. + config BR2_ROOTFS_POST_BUILD_SCRIPT string "Custom script to run before creating filesystem images" default "$(PROJECT_DIR)/post-build.sh" if BR2_PROJECT_DIR != ""