Add support for a project directory

From: Arnout Vandecappelle (Essensium/Mind) <[email protected]>

defconfig file after updating the configuration.

Also use $(PROJECT_DIR) by default.

As a side-effect of this change, the *config options have been moved out of the BR2_HAVE_DOT_CONFIG condition. Also, the defconfig and savedefconfig targets do need to include .config now, which makes them slightly slower.

Signed-off-by Arnout Vandecappelle (Essensium/Mind) <[email protected]>

---
 Config.in |   13 +++++++++++++
 Makefile  |   22 +++++++++++++---------
 2 files changed, 26 insertions(+), 9 deletions(-)

Config.in +13 -0

index 8cefcc6..4111409 100644
@@ -29,6 +29,19 @@ config BR2_PROJECT_DIR
          This option is used to set defaults for many other configuration
          variables.  Each one of those can still be overridden individually.
 
+config BR2_DEFCONFIG_FROM_ENV
+       string
+       option env="BR2_DEFCONFIG"
+
+config BR2_DEFCONFIG
+       string "Location to save buildroot config"
+       default "$(PROJECT_DIR)/buildroot.config" if BR2_PROJECT_DIR != ""
+       default BR2_DEFCONFIG_FROM_ENV if BR2_DEFCONFIG_FROM_ENV != ""
+       default "defconfig"
+       help
+         When running 'make savedefconfig', the defconfig file will be saved
+         in this location.
+
 menu "Build options"
 
 menu "Commands"

Makefile +12 -8

index d6136ed..cbaa0c4 100644
@@ -56,7 +56,7 @@ DATE:=$(shell date +%Y%m%d)
 export BR2_VERSION_FULL:=$(BR2_VERSION)$(shell $(TOPDIR)/support/scripts/setlocalversion)
 
 noconfig_targets:=menuconfig nconfig gconfig xconfig config oldconfig randconfig \
-       defconfig %_defconfig savedefconfig allyesconfig allnoconfig silentoldconfig release \
+       %_defconfig allyesconfig allnoconfig silentoldconfig release \
        randpackageconfig allyespackageconfig allnopackageconfig \
        source-check print-version
 

@@ -97,6 +97,7 @@ ifeq ($(filter $(noconfig_targets),$(MAKECMDGOALS)),)
 endif
 
 PROJECT_DIR = $(realpath $(call qstrip,$(BR2_PROJECT_DIR)))
+DEFCONFIG = $(call qstrip,$(BR2_DEFCONFIG))
 
 # To put more focus on warnings, be less verbose as default
 # Use 'make V=1' to see the full commands

@@ -545,6 +546,8 @@ else # ifeq ($(BR2_HAVE_DOT_CONFIG),y)
 
 all: menuconfig
 
+endif # ifeq ($(BR2_HAVE_DOT_CONFIG),y)
+
 # configuration
 # ---------------------------------------------------------------------------
 

@@ -560,6 +563,7 @@ COMMON_CONFIG_ENV = \
        KCONFIG_AUTOHEADER=$(BUILD_DIR)/buildroot-config/autoconf.h \
        KCONFIG_TRISTATE=$(BUILD_DIR)/buildroot-config/tristate.config \
        BR2_PROJECT_DIR=$(PROJECT_DIR) \
+       BR2_DEFCONFIG=$(DEFCONFIG) \
        BUILDROOT_CONFIG=$(CONFIG_DIR)/.config
 
 xconfig: $(BUILD_DIR)/buildroot-config/qconf outputmakefile

@@ -626,24 +630,24 @@ silentoldconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile
        @mkdir -p $(BUILD_DIR)/buildroot-config
        $(COMMON_CONFIG_ENV) $< --silentoldconfig $(CONFIG_CONFIG_IN)
 
-defconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile
-       @mkdir -p $(BUILD_DIR)/buildroot-config
-       @$(COMMON_CONFIG_ENV) $< --defconfig$(if $(BR2_DEFCONFIG),=$(BR2_DEFCONFIG)) $(CONFIG_CONFIG_IN)
-
 %_defconfig: $(BUILD_DIR)/buildroot-config/conf $(TOPDIR)/configs/%_defconfig outputmakefile
        @mkdir -p $(BUILD_DIR)/buildroot-config
        @$(COMMON_CONFIG_ENV) $< --defconfig=$(TOPDIR)/configs/$@ $(CONFIG_CONFIG_IN)
 
+defconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile
+       @mkdir -p $(BUILD_DIR)/buildroot-config
+       @$(COMMON_CONFIG_ENV) $< --defconfig$(if $(DEFCONFIG),=$(DEFCONFIG)) $(CONFIG_CONFIG_IN)
+
 savedefconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile
        @mkdir -p $(BUILD_DIR)/buildroot-config
-       @$(COMMON_CONFIG_ENV) $< --savedefconfig=$(CONFIG_DIR)/defconfig $(CONFIG_CONFIG_IN)
+       @$(COMMON_CONFIG_ENV) $< \
+               --savedefconfig=$(if $(DEFCONFIG),$(DEFCONFIG),$(CONFIG_DIR)/defconfig) \
+               $(CONFIG_CONFIG_IN)
 
 # check if download URLs are outdated
 source-check:
        $(MAKE) DL_MODE=SOURCE_CHECK $(EXTRAMAKEARGS) source
 
-endif # ifeq ($(BR2_HAVE_DOT_CONFIG),y)
-
 #############################################################
 #
 # Cleanup and misc junk

From: Arnout Vandecappelle (Essensium/Mind) <[email protected]>

The update-all-config target updates all the external configuration file with their current values. This includes:
- buildroot
- busybox
- linux
- crosstool-ng
- uClibc

Signed-off-by Arnout Vandecappelle (Essensium/Mind) <[email protected]>

---
Barebox is missing because there is no BR2_TARGET_BAREBOX_CONFIG option.

---
 Makefile                                         |    6 ++++++
 linux/linux.mk                                   |    2 ++
 package/busybox/busybox.mk                       |    4 ++++
 toolchain/toolchain-crosstool-ng/crosstool-ng.mk |    7 +++++++
 toolchain/uClibc/uclibc.mk                       |    4 ++++
 5 files changed, 23 insertions(+)

Makefile +6 -0

index 1f42141..0e5b28e 100644
@@ -660,6 +660,10 @@ savedefconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile
                --savedefconfig=$(if $(DEFCONFIG),$(DEFCONFIG),$(CONFIG_DIR)/defconfig) \
                $(CONFIG_CONFIG_IN)
 
+# UPDATE_ALL_CONFIG_TARGETS is set by the individual packages that have a
+# save*config target.
+update-all-config: savedefconfig $(UPDATE_ALL_CONFIG_TARGETS)
+
 # check if download URLs are outdated
 source-check:
        $(MAKE) DL_MODE=SOURCE_CHECK $(EXTRAMAKEARGS) source

@@ -714,6 +718,8 @@ help:
        @echo '  defconfig              - New config with default answer to all options'
        @echo '                             BR2_DEFCONFIG, if set, is used as input'
        @echo '  savedefconfig          - Save current config as ./defconfig (minimal config)'
+       @echo '  update-all-config      - Update all configuration targets that have an input:'
+       @echo '                           buildroot, busybox, linux, crosstool-ng, uClibc'
        @echo '  allyesconfig           - New config where all options are accepted with yes'
        @echo '  allnoconfig            - New config where all options are answered with no'
        @echo '  randpackageconfig      - New config with random answer to package options'

linux/linux.mk +2 -0

index c4bdf90..98ffe44 100644
@@ -151,6 +151,8 @@ ifeq ($(BR2_LINUX_KERNEL_USE_DEFCONFIG),y)
 KERNEL_SOURCE_CONFIG = $(KERNEL_ARCH_PATH)/configs/$(call qstrip,$(BR2_LINUX_KERNEL_DEFCONFIG))_defconfig
 else ifeq ($(BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG),y)
 KERNEL_SOURCE_CONFIG = $(BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE)
+# savedefconfig requires a kernel >= 2.6.33
+UPDATE_ALL_CONFIG_TARGETS += linux-update-defconfig
 endif
 
 define LINUX_CONFIGURE_CMDS

package/busybox/busybox.mk +4 -0

index 33f8633..5063a8b 100644
@@ -217,3 +217,7 @@ busybox-menuconfig busybox-xconfig busybox-gconfig: busybox-patch
 
 busybox-update-config:
        cp -f $(BUSYBOX_BUILD_CONFIG) $(BUSYBOX_CONFIG_FILE)
+
+ifneq ($(BUSYBOX_CONFIG_FILE),)
+UPDATE_ALL_CONFIG_TARGETS += busybox-update-config
+endif

toolchain/toolchain-crosstool-ng/crosstool-ng.mk +0 -0

index d18f5d5..688bcfe 100644

busybox-update-config:

        cp -f $(BUSYBOX_BUILD_CONFIG) $(BUSYBOX_CONFIG_FILE)

toolchain/uClibc/uclibc.mk +0 -0

index d1cd718..0faaf18 100644

Quoted 7 lines

+

Quoted 6 lines

+ctng-update-config: $(CTNG_DIR)/.config
+ $(Q)cp $< $(CTNG_CONFIG_FILE)
+
+ifneq ($(CTNG_CONFIG_FILE),)
+UPDATE_ALL_CONFIG_TARGETS += ctng-update-config
+endif

I would personally have split the addition of an update-config feature for crosstool-ng from this patch that wraps the different update-config targets in one update-all-config.

I wonder why ctng-update-config uses a different type of recipe than their counterparts in busybox, uclibc, ...

For busybox it is:

Quoted 2 lines

Quoted 2 lines

   busybox-update-config:
          cp -f $(BUSYBOX_BUILD_CONFIG) $(BUSYBOX_CONFIG_FILE)

while for ctng, as proposed above:

Quoted 2 lines

Quoted 2 lines

+ctng-update-config: $(CTNG_DIR)/.config
+ $(Q)cp $< $(CTNG_CONFIG_FILE)

Differences:

- target dependency

- $(Q)

- forced copy

I would say that since all these packages are using the same kind of config system, the way to save their config files should also line up. It's possible that the new ctng-update-config is better in some ways, but in this case I think the other ones should be updated as well

Quoted 1 line

- forced copy

Ah, except that cp -f doesn't mean forced copy; it means: remove an
already existing file before the copy. That means that permissions are lost and if it's a symlink, it's not the file it points to that gets updated. So I think cp -f is _not_ what we want here...

Hi,

Quoted 10 lines · Arnout Vandecappelle (Essensium/Mind)

Quoted 10 lines

From: Arnout Vandecappelle (Essensium/Mind) <[email protected]>

The update-all-config target updates all the external configuration file with their current values. This includes:
- buildroot
- busybox
- linux
- crosstool-ng
- uClibc

Quoted 1 line

Quoted 1 line

Signed-off-by Arnout Vandecappelle (Essensium/Mind) <[email protected]>

I like this idea, and would propose to go through with this regardless of the outcome of the series.
See below for some comments though

I'd like to go one step further and put buildroot's default config files in the board/company/product hierarchy, too. Then everything would be in one place.

Signed-off-by Arnout Vandecappelle (Essensium/Mind) <[email protected]>

---
v2: Removed accidental changes to busybox.config and uClibc.config

---
  Makefile              |   30 ++++++++++++++++++++++++++++++
  Makefile.project.tmpl |   40 ++++++++++++++++++++++++++++++++++++++++
  2 files changed, 70 insertions(+)

create mode 100644 Makefile.project.tmpl

Makefile +30 -0

index 0e5b28e..a3b88f7 100644
@@ -698,6 +698,33 @@ endif
 
  cross: $(BASE_TARGETS)
 
+ifneq ($(PROJECT_DIR),)
+ifeq ($(findstring -git,$(BR2_VERSION)),)
+BUILDROOT_VERSION = $(BR2_VERSION)
+else
+BUILDROOT_VERSION = snapshot
+endif
+
+# Write a buildroot config in the project dir, then use that defconfig to
+# re-generate the .config.  This replaces the config file paths with paths
+# pointing into PROJECT_DIR (unless they have been changed from their
+# default values).  The subsequent update-all-config writes all the config
+# files into the PROJECT_DIR.  That last step doesn't need to set PROJECT_DIR
+# or DEFCONFIG anymore, because they're already set in the new .config.
+projectdir:
+	mkdir -p $(PROJECT_DIR)
+	sed s/@BUILDROOT_VERSION@/$(BUILDROOT_VERSION)/g \
+		Makefile.project.tmpl > $(PROJECT_DIR)/Makefile
+	$(MAKE1) $(EXTRAMAKEARGS) \
+		DEFCONFIG=$(PROJECT_DIR)/buildroot.config \
+		savedefconfig
+	$(MAKE1) $(EXTRAMAKEARGS) \
+		PROJECT_DIR=$(PROJECT_DIR) \
+		DEFCONFIG=$(PROJECT_DIR)/buildroot.config \
+		defconfig
+	$(MAKE1) $(EXTRAMAKEARGS) update-all-config
+endif
+
  help:
  	@echo 'Cleaning:'
  	@echo '  clean                  - delete all files created by build'

@@ -756,6 +783,9 @@ endif
  	@echo '  source-check           - check selected packages for valid download URLs'
  	@echo '  external-deps          - list external packages used'
  	@echo '  legal-info             - generate info about license compliance'
+ifneq ($(PROJECT_DIR),)
+	@echo '  projectdir             - Prepare project directory with a Makefile.'
+endif
  	@echo
  	@echo '  make V=0|1             - 0 => quiet build (default), 1 => verbose build'
  	@echo '  make O=dir             - Locate all output files in "dir", including .config'

Makefile.project.tmpl new file +30 -0

new file mode 100644
index 0000000..b41180a
@@ -0,0 +1,40 @@
+# This Makefile creates a build environment using the directory containing
+# this Makefile as the project directory.
+# If called from a different directory using 'make -f ...', the current
+# directory is used as the output directory.
+
+lastword = $(word $(words $(1)),$(1))
+makedir  = $(dir $(call lastword,$(MAKEFILE_LIST)))
+
+BR2_PROJECT_DIR = $(realpath $(makedir))
+BUILDROOT_DIR   = $(BR2_PROJECT_DIR)/buildroot
+BUILDROOT_VERSION = @BUILDROOT_VERSION@
+BUILDROOT_SITE    = http://buildroot.net/downloads
+BUILDROOT_SOURCE  = buildroot-$(BUILDROOT_VERSION).tar.bz2
+
+ifeq ($(O),)
+ifeq ($(makedir),./)
+# Building in project dir => create output dir
+O = $(CURDIR)/output
+else
+# Building from some other dir => use this dir as output dir
+O = $(CURDIR)
+endif
+endif
+
+.PHONY: all $(MAKECMDGOALS)
+
+all: $(BUILDROOT_DIR)
+	@$(MAKE) -C buildroot O=$(O) BR2_PROJECT_DIR=$(BR2_PROJECT_DIR) $(all)
+
+all     := $(filter-out all,$(MAKECMDGOALS))

_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

Makefile.project.tmpl line 40

Quoted 7 lines

+$(BUILDROOT_DIR):

Makefile.project.tmpl new file +6 -0

+    mkdir -p $@
+    wget -O - $(BUILDROOT_SITE)/$(BUILDROOT_SOURCE) | \
+        tar -xjf - -C $@ --strip-components=1
+    for p in `ls $(makedir)/patches/buildroot/buildroot-* 2>/dev/null`; do \
+        patch -d $@ -p1 -i $$p; \
+    done

I probably miss something, but
do I have to download buldroot for every project?
Can I use my local BR git tree as a buildroot source for my projects instead of downloading?

Quoted 9 lines · Valentine Barshak

Makefile.project.tmpl line 40

Quoted 8 lines

+$(BUILDROOT_DIR):

Makefile.project.tmpl new file +4 -0

+    mkdir -p $@
+    wget -O - $(BUILDROOT_SITE)/$(BUILDROOT_SOURCE) | \
+        tar -xjf - -C $@ --strip-components=1
+    for p in `ls $(makedir)/patches/buildroot/buildroot-*

2>/dev/null`; do \

Makefile.project.tmpl new file +2 -0

+        patch -d $@ -p1 -i $$p; \
+    done

Quoted 4 lines

I probably miss something, but
do I have to download buldroot for every project?
Can I use my local BR git tree as a buildroot source for my projects instead of downloading?

No, make a symlink to the BR tree and it won't download anything.

But this automatic download feature is probably going a bridge too far
:-)

Regards,
Arnout

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.

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?

Quoted 14 lines · Danomi Manchego

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.)

Quoted 2 lines

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

--

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

From: Arnout Vandecappelle (Essensium/Mind) <[email protected]>

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) <[email protected]>

---
 Makefile                         |    9 +++++++++
 docs/manual/customize-rootfs.txt |   21 +++++++++------------
 target/generic/Config.in         |   13 +++++++++++++
 3 files changed, 31 insertions(+), 12 deletions(-)

Makefile +9 -0

index a3b88f7..31770ce 100644
@@ -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)

docs/manual/customize-rootfs.txt +9 -12

index 8c3ea82..b3c160b 100644
@@ -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

target/generic/Config.in +13 -0

index 76137b7..35cadfb 100644
@@ -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 at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

Quoted 9 lines · Arnout Vandecappelle (Essensium/Mind)

Quoted 9 lines

From: Arnout Vandecappelle (Essensium/Mind)<[email protected]>

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.

Quoted 1 line

Quoted 1 line

Signed-off-by Arnout Vandecappelle (Essensium/Mind)<[email protected]>

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.

Many buildroot users prefer to keep their project's customizations
separate from buildroot itself. This makes it easier to go to a new buildroot version, and to identify which parts are project- specific. Although it was already possible to keep the project's customization separate, this patch set simplifies it.

It introduces a new config option, BR2_PROJECT_DIR (patch 1).
This symbol is used to set defaults for many other config options (patches 2-7). The buildroot config itself can also be stored in the project directory by setting a default BR2_DEFCONFIG (patch 8).

Patch 9 does a 'make defconfig' and 'make world' in a single run
when a project directory is available.

Patch 10 makes it possible to update all config files (buildroot,
linux, busybox, ...) in a single shot.

Patch 11 adds a 'make projectdir' target to initialize a project
directory. It also creates a Makefile in the project directory:
it downloads buildroot itself, so the project directory is self-sufficient.

Patch 12 adds the thing that everybody has to put in their
post-build script as a configuration option: a rootfs overlay. This patch could also be applied independent of the series (except for the one line that sets a default based on PROJECT_DIR).

Patch 13, finally, adds the PROJECT_DIR concept to the manual.

So I'll have a look, but my initial impression is one of fairly high skepticism, to say the least.

Quoted 2 lines · Thomas Petazzoni

So I'll have a look, but my initial impression is one of fairly high skepticism, to say the least.

Ok, I had a look, and I'm going to NAK this.

All what this stuff is adding can already be done with the current Buildroot, by putting the configuration files in a board/something/foo directory, and adjusting the Buildroot configuration.

It just adds a
useless layer with a fuzzy concept of "project" that we had in the past, and was a terrible idea.

Moreover, the introduction text states that "Many buildroot users prefer to keep their project's customizations separate from buildroot itself", but the patch set doesn't solve this problem at all:

* Custom packages are not taken into account

* Additional patches added to existing packages are not taken into account

* Modification to the recipes of existing packages are not taken into account. And it is very common for a project that you need to slightly upgrade or adjust the recipe of a few existing packages.

So even with this additional complexity,

the most annoying problems are
not solved. So I really do prefer to keep things as it is: people have to use version control systems to keep their changes cleanly separated from the base Buildroot version.

A half-working solution is not going
to help our users to understand how to properly use Buildroot.

If we want to really separate the project specificities, then we need to introduce a real concept of "layers" like OpenEmbedded has, which allows to also override package recipes, add new custom packages, etc. But I am not sure we want to go down this road.

Quoted 3 lines

All what this stuff is adding can already be done with the current Buildroot, by putting the configuration files in a board/something/foo directory, and adjusting the Buildroot configuration.

It doesn't even have to be in a board/something/foo directory, it can
easily be out of tree. The only problem is that you have to write down a fairly long path for each of the relevant config options.

Quoted 3 lines

It just adds a
useless layer with a fuzzy concept of "project" that we had in the past, and was a terrible idea.

That it didn't work in the past doesn't mean it's a terrible idea :-)

Quoted 3 lines

Moreover, the introduction text states that "Many buildroot users prefer to keep their project's customizations separate from buildroot itself", but the patch set doesn't solve this problem at all:

It's not a "problem", because it is already possible now - I've done
it for my last four buildroot projects (without any modification to stock buildroot), and I find it _much_ more convenient than before to upgrade buildroot - particularly if I just want to test that particular project against current master. But the main advantage is that you can nicely separate the things which are proprietary from the things that are potentially upstreamable (because those are still applied in the buildroot tree itself).

Quoted 1 line

* Custom packages are not taken into account

  In $(PROJECT_DIR)/project.mk, add:

BR2_PACKAGE_FOO=y
include package/foo/foo.mk

Quoted 2 lines

* Additional patches added to existing packages are not taken into account

You can add a post-patch hook in project.mk. It's a bit more involved,
that's why I propose to automate that in the package infrastructure. But I haven't needed that up to now so I don't have a solution ready, and I'm not going to spend time on it if it will be NAK'd anyway :-)

For the things that do frequently need patches (linux, u-boot, ...)
we already have config options, so we could just add PROJECT_DIR-based defaults for those as well.

Quoted 3 lines

* Modification to the recipes of existing packages are not taken into account. And it is very common for a project that you need to slightly upgrade or adjust the recipe of a few existing packages.

Indeed. Those changes should still go in the buildroot tree itself.

Quoted 1 line

So even with this additional complexity,

Complexity? The diffstat of patches 1-7 is:

  8 files changed, 30 insertions(+), 2 deletions(-)

The ones after that are more involved, I agree.

Quoted 4 lines

the most annoying problems are
not solved. So I really do prefer to keep things as it is: people have to use version control systems to keep their changes cleanly separated from the base Buildroot version.

Version control doesn't really solve it, in my experience.

Quoted 7 lines

A half-working solution is not going
to help our users to understand how to properly use Buildroot.

If we want to really separate the project specificities, then we need to introduce a real concept of "layers" like OpenEmbedded has, which allows to also override package recipes, add new custom packages, etc. But I am not sure we want to go down this road.

I'm pretty sure we don't want to go down that road. I don't believe
the possibility of overriding package recipes is warranted. I also don't think it's very useful in our context to have several layers. The only thing I want is to keep the customizations (i.e. configuration, skeleton, etc.) in a separate directory tree from buildroot.

Arnout,

Quoted 4 lines · Arnout Vandecappelle

Quoted 3 lines

All what this stuff is adding can already be done with the current Buildroot, by putting the configuration files in a board/something/foo directory, and adjusting the Buildroot configuration.

Quoted 3 lines

It doesn't even have to be in a board/something/foo directory, it can
easily be out of tree. The only problem is that you have to write down a fairly long path for each of the relevant config options.

Come on, it's just something like:

	$(TOPDIR)/../myproject/linux.config

I still don't get what this patch set adds that you can't do with the existing Buildroot infrastructure.

I really would prefer to _document_ how to properly use the existing Buildroot infrastructure to cleanly separate custom stuff from Buildroot, rather than introducing more mechanisms on top of it.

It's not a question of diffstat. It's a question of "is this mechanism easy to grasp for newcomers and can it be immediately understood" and "does this mechanism adds any value over what Buildroot already provides"?

Quoted 6 lines

Quoted 4 lines

the most annoying problems are
not solved. So I really do prefer to keep things as it is: people have to use version control systems to keep their changes cleanly separated from the base Buildroot version.

Version control doesn't really solve it, in my experience.

Why so?

I'll have a close look at all this later, but for reference, this is almost exactly a feature that Buildroot had years ago, and that we painfully progressively removed because it was not used properly by anyone, and was crippling the code base and usage of Buildroot with a lot of useless complexity.

Sorry that I'm not letting this go, but: how is this similar to the
project concept that was removed in 2009? I'm not trying to share any of the build output between different projects -- the only thing that is shared is the buildroot directory.

Sorry that I'm not letting this go, but: how is this similar to the
project concept that was removed in 2009? I'm not trying to share any of the build output between different projects -- the only thing that is shared is the buildroot directory.

Many buildroot users prefer to keep their project's customizations
separate from buildroot itself. This makes it easier to go to a new buildroot version, and to identify which parts are project- specific. Although it was already possible to keep the project's customization separate, this patch set simplifies it.

It introduces a new config option, BR2_PROJECT_DIR (patch 1).
This symbol is used to set defaults for many other config options (patches 2-7). The buildroot config itself can also be stored in the project directory by setting a default BR2_DEFCONFIG (patch 8).

Patch 9 does a 'make defconfig' and 'make world' in a single run
when a project directory is available.

Patch 10 makes it possible to update all config files (buildroot,
linux, busybox, ...) in a single shot.

Patch 11 adds a 'make projectdir' target to initialize a project
directory. It also creates a Makefile in the project directory:
it downloads buildroot itself, so the project directory is self-sufficient.

Patch 12 adds the thing that everybody has to put in their
post-build script as a configuration option: a rootfs overlay. This patch could also be applied independent of the series (except for the one line that sets a default based on PROJECT_DIR).

Patch 13, finally, adds the PROJECT_DIR concept to the manual.

What is still missing is a way to add custom packages and custom
patches in the project directory. Either can already be done with the BR2_PACKAGE_OVERRIDE_FILE, but I'm considering specific additions:

- For custom packages, including $(PROJECT_DIR)/package/*/*.mk and automatically setting these packages to 'y'. I don't think it's useful to include custom packages in the menuconfig - you just want them to be always enabled.

- For custom patches, add $(PROJECT_DIR)/patches/<pkg>/<pkg>-*.patch to the list of patches that generic-package looks for. The custom patches would come in addition to and after the buildroot patches.

Comments on these last two ideas are welcome.

Two weeks from now (Oct. 28) I'm giving a presentation about buildroot
at T-Dose in Eindhoven. I'll use the project directory concept in that presentation. So if there's any major feedback I'd like to hear it before that time :-)

---

Arnout Vandecappelle (Essensium/Mind) (13):
Add BR2_PROJECT_DIR config option
Set default BR2_PACKAGE_OVERRIDE_FILE based on BR2_PROJECT_DIR
linux: get default paths from BR2_PROJECT_DIR
busybox: get default paths from BR2_PROJECT_DIR target/generic: get default paths from BR2_PROJECT_DIR
toolchain-crosstool-ng: get default paths from BR2_PROJECT_DIR
uClibc: get default paths from BR2_PROJECT_DIR
Store BR2_DEFCONFIG in .config, and use it to update the original input Skip menuconfig if BR2_DEFCONFIG or BR2_PROJECT_DIR is given. Add update-all-config target
Add target to create a project directory
target/generic: add filesystem overlay option
Document BR2_PROJECT_DIR in the manual

 Config.in                                        |   27 +++++++
 Makefile                                         |   86 +++++++++++++++++++--
 Makefile.project.tmpl                            |   40 ++++++++++
 docs/manual/customize-project.txt                |   37 +++++++++
 docs/manual/customize-rootfs.txt                 |   21 ++---
 docs/manual/customize.txt                        |    2
 fs/common.mk                                     |    7 +-
 linux/Config.in                                  |    2
 linux/linux.mk                                   |    2
 package/busybox/Config.in                        |    1
 package/busybox/busybox-1.20.x.config            |   26 +++---
 package/busybox/busybox.mk                       |    4 +
 target/generic/Config.in                         |   16 ++++
 toolchain/toolchain-crosstool-ng/Config.in       |    1
 toolchain/toolchain-crosstool-ng/crosstool-ng.mk |    7 ++
 toolchain/uClibc/Config.in                       |    1
 toolchain/uClibc/uClibc-0.9.33.config            |   91 +++++++++-------------
 toolchain/uClibc/uclibc.mk                       |    4 +
 18 files changed, 286 insertions(+), 89 deletions(-)
 create mode 100644 Makefile.project.tmpl
 create mode 100644 docs/manual/customize-project.txt

--
Signature
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot