[Buildroot] [PATCH 00/13] Add support for a project directory

[Buildroot] [PATCH 00/13] Add support for a project directory

[Arnout Vandecappelle]

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

 Regards,
 Arnout

---

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] [PATCH 01/13] Add BR2_PROJECT_DIR config option

[Arnout Vandecappelle]

From: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>

This option will be used by subsequent patches to set default values
for paths.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 Config.in |   13 +++++++++++++
 Makefile  |    3 +++
 2 files changed, 16 insertions(+)

diff --git a/Config.in b/Config.in
index dab7787..438964a 100644
--- a/Config.in
+++ b/Config.in
@@ -16,6 +16,19 @@ config BR2_HOSTARCH
 
 source "target/Config.in.arch"
 
+# BR2_DEFCONFIG must be set through two configs, because 'option env='
+# removes it from the .config.
+config BR2_PROJECT_DIR_FROM_ENV
+	string
+	option env="BR2_PROJECT_DIR"
+
+config BR2_PROJECT_DIR
+	string "Project directory"
+	default BR2_PROJECT_DIR_FROM_ENV
+	help
+	  This option is used to set defaults for many other configuration
+	  variables.  Each one of those can still be overridden individually.
+
 menu "Build options"
 
 menu "Commands"
diff --git a/Makefile b/Makefile
index 0128839..d6136ed 100644
--- a/Makefile
+++ b/Makefile
@@ -96,6 +96,8 @@ ifeq ($(filter $(noconfig_targets),$(MAKECMDGOALS)),)
 -include $(CONFIG_DIR)/.config
 endif
 
+PROJECT_DIR = $(realpath $(call qstrip,$(BR2_PROJECT_DIR)))
+
 # To put more focus on warnings, be less verbose as default
 # Use 'make V=1' to see the full commands
 ifdef V
@@ -557,6 +559,7 @@ COMMON_CONFIG_ENV = \
 	KCONFIG_AUTOCONFIG=$(BUILD_DIR)/buildroot-config/auto.conf \
 	KCONFIG_AUTOHEADER=$(BUILD_DIR)/buildroot-config/autoconf.h \
 	KCONFIG_TRISTATE=$(BUILD_DIR)/buildroot-config/tristate.config \
+	BR2_PROJECT_DIR=$(PROJECT_DIR) \
 	BUILDROOT_CONFIG=$(CONFIG_DIR)/.config
 
 xconfig: $(BUILD_DIR)/buildroot-config/qconf outputmakefile

[Buildroot] [PATCH 02/13] Set default BR2_PACKAGE_OVERRIDE_FILE based on BR2_PROJECT_DIR

[Arnout Vandecappelle]

From: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 Config.in |    1 +
 1 file changed, 1 insertion(+)

diff --git a/Config.in b/Config.in
index 438964a..8cefcc6 100644
--- a/Config.in
+++ b/Config.in
@@ -420,6 +420,7 @@ config BR2_HAVE_DEVFILES
 
 config BR2_PACKAGE_OVERRIDE_FILE
 	string "location of a package override file"
+	default "$(PROJECT_DIR)/project.mk" if BR2_PROJECT_DIR != ""
 	default "$(TOPDIR)/local.mk"
 	help
 	  A package override file is a short makefile that contains

[Buildroot] [PATCH 03/13] linux: get default paths from BR2_PROJECT_DIR

[Arnout Vandecappelle]

From: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
I'm not very happy with the default name 'linux.dts' for the device tree.
However, I haven't got a reasonable alternative.
---
 linux/Config.in |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/linux/Config.in b/linux/Config.in
index 257f934..cf8352d 100644
--- a/linux/Config.in
+++ b/linux/Config.in
@@ -121,6 +121,7 @@ config BR2_LINUX_KERNEL_DEFCONFIG
 config BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE
 	string "Configuration file path"
 	depends on BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG
+	default "$(PROJECT_DIR)/linux.config" if BR2_PROJECT_DIR != ""
 	help
 	  Path to the kernel configuration file
 
@@ -269,6 +270,7 @@ config BR2_LINUX_KERNEL_INTREE_DTS_NAME
 config BR2_LINUX_KERNEL_CUSTOM_DTS_PATH
 	string "Device Tree Source file path"
 	depends on BR2_LINUX_KERNEL_USE_CUSTOM_DTS
+	default "$(PROJECT_DIR)/linux.dts" if BR2_PROJECT_DIR != ""
 	help
 	  Path to the device tree source file
 

[Buildroot] [PATCH 04/13] busybox: get default paths from BR2_PROJECT_DIR

[Arnout Vandecappelle]

From: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 package/busybox/Config.in |    1 +
 1 file changed, 1 insertion(+)

diff --git a/package/busybox/Config.in b/package/busybox/Config.in
index dedcf18..020e5c2 100644
--- a/package/busybox/Config.in
+++ b/package/busybox/Config.in
@@ -40,6 +40,7 @@ config BR2_BUSYBOX_VERSION
 
 config BR2_PACKAGE_BUSYBOX_CONFIG
 	string "BusyBox configuration file to use?"
+	default "$(PROJECT_DIR)/busybox.config" if BR2_PROJECT_DIR != ""
 	default "package/busybox/busybox-1.20.x.config" if BR2_PACKAGE_BUSYBOX_SNAPSHOT
 	default "package/busybox/busybox-1.18.x.config" if BR2_BUSYBOX_VERSION_1_18_X
 	default "package/busybox/busybox-1.19.x.config" if BR2_BUSYBOX_VERSION_1_19_X

[Buildroot] [PATCH 05/13] target/generic: get default paths from BR2_PROJECT_DIR

[Arnout Vandecappelle]

From: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 fs/common.mk             |    7 +++++--
 target/generic/Config.in |    3 +++
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/fs/common.mk b/fs/common.mk
index 0f0eae9..bec0921 100644
--- a/fs/common.mk
+++ b/fs/common.mk
@@ -33,8 +33,11 @@
 
 FAKEROOT_SCRIPT = $(BUILD_DIR)/_fakeroot.fs
 FULL_DEVICE_TABLE = $(BUILD_DIR)/_device_table.txt
-ROOTFS_DEVICE_TABLES = $(call qstrip,$(BR2_ROOTFS_DEVICE_TABLE)) \
-	$(call qstrip,$(BR2_ROOTFS_STATIC_DEVICE_TABLE))
+# The default device tables in $(PROJECT_DIR) may not exist, so
+# verify that.
+ROOTFS_DEVICE_TABLES = \
+	$(wildcard $(call qstrip,$(BR2_ROOTFS_DEVICE_TABLE)) \
+	           $(call qstrip,$(BR2_ROOTFS_STATIC_DEVICE_TABLE)))
 
 define ROOTFS_TARGET_INTERNAL
 
diff --git a/target/generic/Config.in b/target/generic/Config.in
index b8472f4..76137b7 100644
--- a/target/generic/Config.in
+++ b/target/generic/Config.in
@@ -71,6 +71,7 @@ endchoice
 
 config BR2_ROOTFS_DEVICE_TABLE
 	string "Path to the permission tables"
+	default "$(PROJECT_DIR)/device_table.txt target/generic/device_table.txt" if BR2_PROJECT_DIR != ""
 	default "target/generic/device_table.txt"
 	help
 	  Specify a space-separated list of permission table locations,
@@ -83,6 +84,7 @@ config BR2_ROOTFS_DEVICE_TABLE
 
 config BR2_ROOTFS_STATIC_DEVICE_TABLE
 	string "Path to the device tables"
+	default "$(PROJECT_DIR)/device_table_dev.txt target/generic/device_table_dev.txt" if BR2_PROJECT_DIR != ""
 	default "target/generic/device_table_dev.txt"
 	depends on BR2_ROOTFS_DEVICE_CREATION_STATIC
 	help
@@ -168,6 +170,7 @@ endif # BR2_ROOTFS_SKELETON_DEFAULT
 
 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 != ""
 	default ""
 	help
 	  Specify a script to be run after the build has finished and before

[Buildroot] [PATCH 06/13] toolchain-crosstool-ng: get default paths from BR2_PROJECT_DIR

[Arnout Vandecappelle]

From: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 toolchain/toolchain-crosstool-ng/Config.in |    1 +
 1 file changed, 1 insertion(+)

diff --git a/toolchain/toolchain-crosstool-ng/Config.in b/toolchain/toolchain-crosstool-ng/Config.in
index 35ea2b1..9a08768 100644
--- a/toolchain/toolchain-crosstool-ng/Config.in
+++ b/toolchain/toolchain-crosstool-ng/Config.in
@@ -36,6 +36,7 @@ config BR2_TOOLCHAIN_CTNG_LIBC
 
 config BR2_TOOLCHAIN_CTNG_CONFIG
 	string "crosstool-NG configuration file to use"
+	default "$(PROJECT_DIR)/crosstool-ng.config" if BR2_PROJECT_DIR != ""
 	default "toolchain/toolchain-crosstool-ng/crosstool-ng.config-uClibc" if BR2_TOOLCHAIN_CTNG_uClibc
 	default "toolchain/toolchain-crosstool-ng/crosstool-ng.config-eglibc" if BR2_TOOLCHAIN_CTNG_eglibc
 	default "toolchain/toolchain-crosstool-ng/crosstool-ng.config-glibc"  if BR2_TOOLCHAIN_CTNG_glibc

[Buildroot] [PATCH 07/13] uClibc: get default paths from BR2_PROJECT_DIR

[Arnout Vandecappelle]

From: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 toolchain/uClibc/Config.in |    1 +
 1 file changed, 1 insertion(+)

diff --git a/toolchain/uClibc/Config.in b/toolchain/uClibc/Config.in
index f46a415..9db0cfc 100644
--- a/toolchain/uClibc/Config.in
+++ b/toolchain/uClibc/Config.in
@@ -42,6 +42,7 @@ config BR2_UCLIBC_VERSION_STRING
 
 config BR2_UCLIBC_CONFIG
 	string "uClibc configuration file to use?"
+	default "$(PROJECT_DIR)/uClibc.config" if BR2_PROJECT_DIR != ""
 	default "toolchain/uClibc/uClibc-0.9.31.config" if BR2_UCLIBC_VERSION_0_9_31
 	default "toolchain/uClibc/uClibc-0.9.32.config" if BR2_UCLIBC_VERSION_0_9_32
 	default "toolchain/uClibc/uClibc-0.9.33.config" if BR2_UCLIBC_VERSION_0_9_33

[Buildroot] [PATCH 08/13] Store BR2_DEFCONFIG in .config, and use it to update the original input

[Arnout Vandecappelle]

From: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>

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) <arnout@mind.be>
---
 Config.in |   13 +++++++++++++
 Makefile  |   22 +++++++++++++---------
 2 files changed, 26 insertions(+), 9 deletions(-)

diff --git a/Config.in b/Config.in
index 8cefcc6..4111409 100644
--- a/Config.in
+++ b/Config.in
@@ -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"
diff --git a/Makefile b/Makefile
index d6136ed..cbaa0c4 100644
--- a/Makefile
+++ b/Makefile
@@ -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
@@ -757,5 +761,5 @@ print-version:
 
 include docs/manual/manual.mk
 
-.PHONY: $(noconfig_targets)
+.PHONY: $(noconfig_targets) defconfig savedefconfig
 

[Buildroot] [PATCH 08/13] Store BR2_DEFCONFIG in .config, and use it to update the original input

[Thomas De Schampheleire]

Hi,

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>
>
> defconfig file after updating the configuration.

The patch title+description are awkwardly split.

>
> 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) <arnout@mind.be>
> ---
>  Config.in |   13 +++++++++++++
>  Makefile  |   22 +++++++++++++---------
>  2 files changed, 26 insertions(+), 9 deletions(-)
>
> diff --git a/Config.in b/Config.in
> index 8cefcc6..4111409 100644
> --- a/Config.in
> +++ b/Config.in
> @@ -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"
> diff --git a/Makefile b/Makefile
> index d6136ed..cbaa0c4 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -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
> @@ -757,5 +761,5 @@ print-version:
>
>  include docs/manual/manual.mk
>
> -.PHONY: $(noconfig_targets)
> +.PHONY: $(noconfig_targets) defconfig savedefconfig
>
>

Regardless of whether the PROJECT_DIR is accepted or not, I like some
of the patches of the set.
I have proposed a patch similar to this one in the past, so obviously
I'm in favor of this idea of being able to easily save also the
buildroot config directly in the right location.

For busybox, uclibc, etc. it was already possible in one step (make
update-busybox-config) while for buildroot .config it was in two
steps: make savedefconfig && mv defconfig configs/....

Best regards,
Thomas

[Buildroot] [PATCH 09/13] Skip menuconfig if BR2_DEFCONFIG or BR2_PROJECT_DIR is given.

[Arnout Vandecappelle]

From: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>

If BR2_DEFCONFIG or BR2_PROJECT_DIR is given on the command line and
it exists, there is no need to go through menuconfig and we can
build immediately.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 Makefile |   16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/Makefile b/Makefile
index cbaa0c4..1f42141 100644
--- a/Makefile
+++ b/Makefile
@@ -544,8 +544,24 @@ show-targets:
 
 else # ifeq ($(BR2_HAVE_DOT_CONFIG),y)
 
+ifneq ($(PROJECT_DIR),)
+ifeq ($(DEFCONFIG),)
+DEFCONFIG = $(wildcard $(PROJECT_DIR)/buildroot.config)
+endif
+endif
+
+ifeq ($(DEFCONFIG),)
+
 all: menuconfig
 
+else # ifeq ($(DEFCONFIG),)
+
+# Re-run make if necessary
+all world: defconfig
+	$(MAKE) $(EXTRAMAKEARGS) $@
+
+endif # ifeq ($(DEFCONFIG),)
+
 endif # ifeq ($(BR2_HAVE_DOT_CONFIG),y)
 
 # configuration

[Buildroot] [PATCH 10/13] Add update-all-config target

[Arnout Vandecappelle]

From: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>

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) <arnout@mind.be>
---
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(+)

diff --git a/Makefile b/Makefile
index 1f42141..0e5b28e 100644
--- a/Makefile
+++ b/Makefile
@@ -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'
diff --git a/linux/linux.mk b/linux/linux.mk
index c4bdf90..98ffe44 100644
--- a/linux/linux.mk
+++ b/linux/linux.mk
@@ -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
diff --git a/package/busybox/busybox.mk b/package/busybox/busybox.mk
index 33f8633..5063a8b 100644
--- a/package/busybox/busybox.mk
+++ b/package/busybox/busybox.mk
@@ -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
diff --git a/toolchain/toolchain-crosstool-ng/crosstool-ng.mk b/toolchain/toolchain-crosstool-ng/crosstool-ng.mk
index d18f5d5..688bcfe 100644
--- a/toolchain/toolchain-crosstool-ng/crosstool-ng.mk
+++ b/toolchain/toolchain-crosstool-ng/crosstool-ng.mk
@@ -397,3 +397,10 @@ ctng-menuconfig: $(CTNG_DIR)/.config
 	$(call ctng-oldconfig,$<)
 	$(call ctng-check-config-changed,$<,$<.timestamp)
 	$(Q)rm -f $<.timestamp
+
+ctng-update-config: $(CTNG_DIR)/.config
+	$(Q)cp $< $(CTNG_CONFIG_FILE)
+
+ifneq ($(CTNG_CONFIG_FILE),)
+UPDATE_ALL_CONFIG_TARGETS += ctng-update-config
+endif
diff --git a/toolchain/uClibc/uclibc.mk b/toolchain/uClibc/uclibc.mk
index d1cd718..0faaf18 100644
--- a/toolchain/uClibc/uclibc.mk
+++ b/toolchain/uClibc/uclibc.mk
@@ -508,6 +508,10 @@ uclibc-oldconfig: $(UCLIBC_DIR)/.oldconfig
 uclibc-update-config: uclibc-config
 	cp -f $(UCLIBC_DIR)/.config $(UCLIBC_CONFIG_FILE)
 
+ifneq ($(UCLIBC_CONFIG_FILE),)
+UPDATE_ALL_CONFIG_TARGETS += uclibc-update-config
+endif
+
 uclibc-configured: gcc_initial kernel-headers $(UCLIBC_DIR)/.configured
 
 uclibc-configured-source: uclibc-source

[Buildroot] [PATCH 10/13] Add update-all-config target

[Thomas De Schampheleire]

Hi,

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 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) <arnout@mind.be>

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.

> ---
> 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(+)
>
> diff --git a/Makefile b/Makefile
> index 1f42141..0e5b28e 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -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'
> diff --git a/linux/linux.mk b/linux/linux.mk
> index c4bdf90..98ffe44 100644
> --- a/linux/linux.mk
> +++ b/linux/linux.mk
> @@ -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
> diff --git a/package/busybox/busybox.mk b/package/busybox/busybox.mk
> index 33f8633..5063a8b 100644
> --- a/package/busybox/busybox.mk
> +++ b/package/busybox/busybox.mk
> @@ -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
> diff --git a/toolchain/toolchain-crosstool-ng/crosstool-ng.mk b/toolchain/toolchain-crosstool-ng/crosstool-ng.mk
> index d18f5d5..688bcfe 100644
> --- a/toolchain/toolchain-crosstool-ng/crosstool-ng.mk
> +++ b/toolchain/toolchain-crosstool-ng/crosstool-ng.mk
> @@ -397,3 +397,10 @@ ctng-menuconfig: $(CTNG_DIR)/.config
>         $(call ctng-oldconfig,$<)
>         $(call ctng-check-config-changed,$<,$<.timestamp)
>         $(Q)rm -f $<.timestamp
> +
> +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:
>  busybox-update-config:
>         cp -f $(BUSYBOX_BUILD_CONFIG) $(BUSYBOX_CONFIG_FILE)

while for ctng, as proposed above:
> +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


> diff --git a/toolchain/uClibc/uclibc.mk b/toolchain/uClibc/uclibc.mk
> index d1cd718..0faaf18 100644
> --- a/toolchain/uClibc/uclibc.mk
> +++ b/toolchain/uClibc/uclibc.mk
> @@ -508,6 +508,10 @@ uclibc-oldconfig: $(UCLIBC_DIR)/.oldconfig
>  uclibc-update-config: uclibc-config
>         cp -f $(UCLIBC_DIR)/.config $(UCLIBC_CONFIG_FILE)
>
> +ifneq ($(UCLIBC_CONFIG_FILE),)
> +UPDATE_ALL_CONFIG_TARGETS += uclibc-update-config
> +endif
> +
>  uclibc-configured: gcc_initial kernel-headers $(UCLIBC_DIR)/.configured
>
>  uclibc-configured-source: uclibc-source
>

Best regards,
Thomas

[Buildroot] [PATCH 10/13] Add update-all-config target

[Arnout Vandecappelle]

On 14/10/12 20:45, Thomas De Schampheleire wrote:
>> +
>> >  +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.

  Good point.


> I wonder why ctng-update-config uses a different type of recipe than
> their counterparts in busybox, uclibc, ...
>
> For busybox it is:
>> >    busybox-update-config:
>> >           cp -f $(BUSYBOX_BUILD_CONFIG) $(BUSYBOX_CONFIG_FILE)
> while for ctng, as proposed above:
>> >  +ctng-update-config: $(CTNG_DIR)/.config
>> >  +       $(Q)cp $<  $(CTNG_CONFIG_FILE)
> Differences:
>
> - target dependency

  linux and uclibc have it, only busybox is missing it.

> - $(Q)

  My bad.

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


> 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

  True, so I'll fix the use of -f in a separate patch. And add the
dependency for busybox as well.


  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
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH 10/13] Add update-all-config target

[Arnout Vandecappelle]

On 20/10/12 18:47, Arnout Vandecappelle wrote:
>> - 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...

  Wrong again, Arnout :-(  The -f only removes the symlink it the file
couldn't be written to in the first place, so it's OK to have it.

  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
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH 10/13] Add update-all-config target

[Stephan Hoffmann]

Am 14.10.2012 20:45, schrieb Thomas De Schampheleire:
> Hi,
>
> 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 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) <arnout@mind.be>
> 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
Hi,

I also like this idea much.

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.

This approach would be similar to that used by uClinux where all
relevant board specific files are in vendors/company/product.

Kind regards

Stephan

-- 
reLinux     -    Stephan Hoffmann
Am Schmidtgrund 124    50765 K?ln
Tel. +49.221.95595-19    Fax: -64
www.reLinux.de     sho at reLinux.de

[Buildroot] [PATCH 10/13] Add update-all-config target

[Thomas Petazzoni]

Dear Stephan Hoffmann,

On Mon, 03 Dec 2012 15:18:11 +0100, Stephan Hoffmann wrote:

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

This is what we had a long time ago, but it was changed for the current
approach.

See the discussion at
http://lists.busybox.net/pipermail/buildroot/2009-October/029556.html
(note: the discussion starts on October 2009, but continues on November
2009, and the mailing list archive doesn't show it as one single
thread).

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 11/13] Add target to create a project directory

[Arnout Vandecappelle]

From: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 Makefile                              |   30 +++++++++++
 Makefile.project.tmpl                 |   40 +++++++++++++++
 package/busybox/busybox-1.20.x.config |   26 +++++----
 toolchain/uClibc/uClibc-0.9.33.config |   91 ++++++++++++++-------------------
 4 files changed, 121 insertions(+), 66 deletions(-)
 create mode 100644 Makefile.project.tmpl

diff --git a/Makefile b/Makefile
index 0e5b28e..a3b88f7 100644
--- a/Makefile
+++ b/Makefile
@@ -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'
diff --git a/Makefile.project.tmpl b/Makefile.project.tmpl
new file mode 100644
index 0000000..b41180a
--- /dev/null
+++ b/Makefile.project.tmpl
@@ -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))
+$(all): all
+        @:
+
+$(BUILDROOT_DIR):
+	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
diff --git a/package/busybox/busybox-1.20.x.config b/package/busybox/busybox-1.20.x.config
index 5525434..84ae428 100644
--- a/package/busybox/busybox-1.20.x.config
+++ b/package/busybox/busybox-1.20.x.config
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
-# Busybox version: 1.20.0
-# Sun Apr 22 10:09:56 2012
+# Busybox version: 1.20.2
+# Wed Sep 26 02:12:42 2012
 #
 CONFIG_HAVE_DOT_CONFIG=y
 
@@ -49,7 +49,7 @@ CONFIG_FEATURE_SUID=y
 # CONFIG_FEATURE_PREFER_APPLETS is not set
 CONFIG_BUSYBOX_EXEC_PATH="/proc/self/exe"
 CONFIG_FEATURE_SYSLOG=y
-# CONFIG_FEATURE_HAVE_RPC is not set
+CONFIG_FEATURE_HAVE_RPC=y
 
 #
 # Build Options
@@ -60,7 +60,7 @@ CONFIG_FEATURE_SYSLOG=y
 # CONFIG_BUILD_LIBBUSYBOX is not set
 # CONFIG_FEATURE_INDIVIDUAL is not set
 # CONFIG_FEATURE_SHARED_BUSYBOX is not set
-# CONFIG_LFS is not set
+CONFIG_LFS=y
 CONFIG_CROSS_COMPILER_PREFIX=""
 CONFIG_SYSROOT=""
 CONFIG_EXTRA_CFLAGS=""
@@ -583,7 +583,7 @@ CONFIG_MOUNT=y
 # CONFIG_FEATURE_MOUNT_VERBOSE is not set
 # CONFIG_FEATURE_MOUNT_HELPERS is not set
 # CONFIG_FEATURE_MOUNT_LABEL is not set
-# CONFIG_FEATURE_MOUNT_NFS is not set
+CONFIG_FEATURE_MOUNT_NFS=y
 CONFIG_FEATURE_MOUNT_CIFS=y
 CONFIG_FEATURE_MOUNT_FLAGS=y
 CONFIG_FEATURE_MOUNT_FSTAB=y
@@ -737,7 +737,7 @@ CONFIG_PING=y
 # CONFIG_PING6 is not set
 CONFIG_FEATURE_FANCY_PING=y
 # CONFIG_WHOIS is not set
-# CONFIG_FEATURE_IPV6 is not set
+CONFIG_FEATURE_IPV6=y
 # CONFIG_FEATURE_UNIX_LOCAL is not set
 # CONFIG_FEATURE_PREFER_IPV4_ADDRESS is not set
 # CONFIG_VERBOSE_RESOLUTION_ERRORS is not set
@@ -783,15 +783,15 @@ CONFIG_FEATURE_IFUPDOWN_IP=y
 # CONFIG_FEATURE_IFUPDOWN_IP_BUILTIN is not set
 # CONFIG_FEATURE_IFUPDOWN_IFCONFIG_BUILTIN is not set
 CONFIG_FEATURE_IFUPDOWN_IPV4=y
-# CONFIG_FEATURE_IFUPDOWN_IPV6 is not set
+CONFIG_FEATURE_IFUPDOWN_IPV6=y
 CONFIG_FEATURE_IFUPDOWN_MAPPING=y
 # CONFIG_FEATURE_IFUPDOWN_EXTERNAL_DHCP is not set
-CONFIG_INETD=y
-CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_ECHO=y
-CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_DISCARD=y
-CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_TIME=y
-CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_DAYTIME=y
-CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_CHARGEN=y
+# CONFIG_INETD is not set
+# CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_ECHO is not set
+# CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_DISCARD is not set
+# CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_TIME is not set
+# CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_DAYTIME is not set
+# CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_CHARGEN is not set
 # CONFIG_FEATURE_INETD_RPC is not set
 CONFIG_IP=y
 CONFIG_FEATURE_IP_ADDRESS=y
diff --git a/toolchain/uClibc/uClibc-0.9.33.config b/toolchain/uClibc/uClibc-0.9.33.config
index eb39df6..e8cce34 100644
--- a/toolchain/uClibc/uClibc-0.9.33.config
+++ b/toolchain/uClibc/uClibc-0.9.33.config
@@ -1,18 +1,19 @@
 #
 # Automatically generated make config: don't edit
-# Version: 0.9.32-git
-# Fri Jul  9 22:31:59 2010
+# Version: 0.9.33.2
+# Sat Oct 13 16:50:09 2012
 #
 # TARGET_alpha is not set
 # TARGET_arm is not set
 # TARGET_avr32 is not set
 # TARGET_bfin is not set
+# TARGET_c6x is not set
 # TARGET_cris is not set
 # TARGET_e1 is not set
 # TARGET_frv is not set
 # TARGET_h8300 is not set
 # TARGET_hppa is not set
-# TARGET_i386 is not set
+TARGET_i386=y
 # TARGET_i960 is not set
 # TARGET_ia64 is not set
 # TARGET_m68k is not set
@@ -28,43 +29,39 @@
 # TARGET_vax is not set
 # TARGET_x86_64 is not set
 # TARGET_xtensa is not set
-# TARGET_c6x is not set
-
-# CONFIG_GENERIC_ARM is not set
-# CONFIG_ARM610 is not set
-# CONFIG_ARM710 is not set
-# CONFIG_ARM7TDMI is not set
-# CONFIG_ARM720T is not set
-# CONFIG_ARM920T is not set
-# CONFIG_ARM922T is not set
-# CONFIG_ARM926T is not set
-# CONFIG_ARM10T is not set
-# CONFIG_ARM1136JF_S is not set
-# CONFIG_ARM1176JZ_S is not set
-# CONFIG_ARM1176JZF_S is not set
-# CONFIG_ARM_CORTEX_M3 is not set
-# CONFIG_ARM_CORTEX_M1 is not set
-# CONFIG_ARM_SA110 is not set
-# CONFIG_ARM_SA1100 is not set
-# CONFIG_ARM_XSCALE is not set
-# CONFIG_ARM_IWMMXT is not set
-
-# COMPILE_IN_THUMB_MODE is not set
-USE_BX=y
 
-TARGET_SUBARCH=""
 #
 # Target Architecture Features and Options
 #
-TARGET_ARCH="none"
+TARGET_ARCH="i386"
 FORCE_OPTIONS_FOR_ARCH=y
+# CONFIG_GENERIC_386 is not set
+# CONFIG_386 is not set
+# CONFIG_486 is not set
+# CONFIG_586 is not set
+# CONFIG_586MMX is not set
+CONFIG_686=y
+# CONFIG_PENTIUMII is not set
+# CONFIG_PENTIUMIII is not set
+# CONFIG_PENTIUM4 is not set
+# CONFIG_K6 is not set
+# CONFIG_K7 is not set
+# CONFIG_ELAN is not set
+# CONFIG_CRUSOE is not set
+# CONFIG_WINCHIPC6 is not set
+# CONFIG_WINCHIP2 is not set
+# CONFIG_CYRIXIII is not set
+# CONFIG_NEHEMIAH is not set
+TARGET_SUBARCH="i686"
+
 #
 # Using ELF file format
 #
-# ARCH_LITTLE_ENDIAN is not set
-# ARCH_BIG_ENDIAN is not set
-# ARCH_WANTS_LITTLE_ENDIAN is not set
-# ARCH_WANTS_BIG_ENDIAN is not set
+ARCH_LITTLE_ENDIAN=y
+
+#
+# Using Little Endian
+#
 ARCH_HAS_MMU=y
 ARCH_USE_MMU=y
 UCLIBC_HAS_FLOATS=y
@@ -73,16 +70,13 @@ DO_C99_MATH=y
 # DO_XSI_MATH is not set
 # UCLIBC_HAS_FENV is not set
 UCLIBC_HAS_LONG_DOUBLE_MATH=y
-KERNEL_HEADERS="/usr/src/linux/include"
+KERNEL_HEADERS="/home/arnout/src/buildroot/output-ext-toolchain-x86_64/toolchain/linux/include"
 HAVE_DOT_CONFIG=y
 
 #
 # General Library Settings
 #
-# HAVE_NO_PIC is not set
 DOPIC=y
-# ARCH_HAS_NO_SHARED is not set
-# ARCH_HAS_NO_LDSO is not set
 HAVE_SHARED=y
 # FORCE_SHAREABLE_TEXT_SEGMENTS is not set
 LDSO_LDD_SUPPORT=y
@@ -99,13 +93,14 @@ LDSO_LD_LIBRARY_PATH=y
 UCLIBC_CTOR_DTOR=y
 # LDSO_GNU_HASH_SUPPORT is not set
 # HAS_NO_THREADS is not set
-LINUXTHREADS_OLD=y
+# LINUXTHREADS_OLD is not set
 # LINUXTHREADS_NEW is not set
-# UCLIBC_HAS_THREADS_NATIVE is not set
+UCLIBC_HAS_THREADS_NATIVE=y
 UCLIBC_HAS_THREADS=y
+UCLIBC_HAS_TLS=y
 # PTHREADS_DEBUG_SUPPORT is not set
 UCLIBC_HAS_SYSLOG=y
-UCLIBC_HAS_LFS=y
+# UCLIBC_HAS_LFS is not set
 # MALLOC is not set
 # MALLOC_SIMPLE is not set
 MALLOC_STANDARD=y
@@ -165,8 +160,6 @@ UCLIBC_HAS_SOCKET=y
 UCLIBC_HAS_IPV4=y
 # UCLIBC_HAS_IPV6 is not set
 # UCLIBC_HAS_RPC is not set
-# UCLIBC_HAS_FULL_RPC is not set
-# UCLIBC_HAS_REENTRANT_RPC is not set
 UCLIBC_USE_NETLINK=y
 UCLIBC_SUPPORT_AI_ADDRCONFIG=y
 # UCLIBC_HAS_BSD_RES_CLOSE is not set
@@ -189,7 +182,6 @@ UCLIBC_HAS_CTYPE_CHECKED=y
 # UCLIBC_HAS_WCHAR is not set
 # UCLIBC_HAS_LOCALE is not set
 UCLIBC_HAS_HEXADECIMAL_FLOATS=y
-# UCLIBC_HAS_GLIBC_DIGIT_GROUPING is not set
 UCLIBC_HAS_GLIBC_CUSTOM_PRINTF=y
 # USE_OLD_VFPRINTF is not set
 UCLIBC_PRINTF_SCANF_POSITIONAL_ARGS=9
@@ -208,7 +200,6 @@ UCLIBC_HAS_STDIO_BUILTIN_BUFFER_NONE=y
 # UCLIBC_HAS_STDIO_GETC_MACRO is not set
 # UCLIBC_HAS_STDIO_PUTC_MACRO is not set
 UCLIBC_HAS_STDIO_AUTO_RW_TRANSITION=y
-# UCLIBC_HAS_FOPEN_LARGEFILE_MODE is not set
 UCLIBC_HAS_FOPEN_EXCLUSIVE_MODE=y
 # UCLIBC_HAS_FOPEN_CLOSEEXEC_MODE is not set
 UCLIBC_HAS_GLIBC_CUSTOM_STREAMS=y
@@ -218,6 +209,7 @@ UCLIBC_HAS_ERRNO_MESSAGES=y
 UCLIBC_HAS_SIGNUM_MESSAGES=y
 # UCLIBC_HAS_SYS_SIGLIST is not set
 UCLIBC_HAS_GNU_GETOPT=y
+UCLIBC_HAS_STDIO_FUTEXES=y
 # UCLIBC_HAS_GNU_GETSUBOPT is not set
 
 #
@@ -248,24 +240,17 @@ HARDWIRED_ABSPATH=y
 #
 # UCLIBC_BUILD_PIE is not set
 # UCLIBC_HAS_ARC4RANDOM is not set
-# HAVE_NO_SSP is not set
-UCLIBC_HAS_SSP=y
-# UCLIBC_HAS_SSP_COMPAT is not set
-# SSP_QUICK_CANARY is not set
-PROPOLICE_BLOCK_ABRT=y
-# PROPOLICE_BLOCK_SEGV is not set
-# UCLIBC_BUILD_SSP is not set
+# UCLIBC_HAS_SSP is not set
 UCLIBC_BUILD_RELRO=y
 UCLIBC_BUILD_NOW=y
 UCLIBC_BUILD_NOEXECSTACK=y
 
 #
-# uClibc development/debugging options
+# Development/debugging options
 #
-CROSS_COMPILER_PREFIX=""
+CROSS_COMPILER_PREFIX="/home/arnout/src/buildroot/output-ext-toolchain-x86_64/host/usr/bin/i686-buildroot-linux-uclibc-"
 UCLIBC_EXTRA_CFLAGS=""
 # DODEBUG is not set
-# DODEBUG_PT is not set
 DOSTRIP=y
 # DOASSERTS is not set
 # SUPPORT_LD_DEBUG is not set

[Buildroot] [PATCH v2] Add target to create a project directory

[Arnout Vandecappelle]

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
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

diff --git a/Makefile b/Makefile
index 0e5b28e..a3b88f7 100644
--- a/Makefile
+++ b/Makefile
@@ -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'
diff --git a/Makefile.project.tmpl b/Makefile.project.tmpl
new file mode 100644
index 0000000..b41180a
--- /dev/null
+++ b/Makefile.project.tmpl
@@ -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))
+$(all): all
+        @:
+
+$(BUILDROOT_DIR):
+	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

[Buildroot] [PATCH v2] Add target to create a project directory

[Valentine Barshak]

On 10/14/2012 03:21 AM, Arnout Vandecappelle (Essensium/Mind) wrote:
> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> ---
> 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
>
> diff --git a/Makefile b/Makefile
> index 0e5b28e..a3b88f7 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -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'
> diff --git a/Makefile.project.tmpl b/Makefile.project.tmpl
> new file mode 100644
> index 0000000..b41180a
> --- /dev/null
> +++ b/Makefile.project.tmpl
> @@ -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))
> +$(all): all
> +        @:
> +
> +$(BUILDROOT_DIR):
> +	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?

Thanks,
Val.
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>

[Buildroot] [PATCH v2] Add target to create a project directory

[Arnout Vandecappelle]

On 14/10/12 01:35, Valentine Barshak wrote:
>> +$(BUILDROOT_DIR):
>> +    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?

  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

-- 
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
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH v2] Add target to create a project directory

[Valentine Barshak]

On 10/14/2012 04:50 PM, Arnout Vandecappelle wrote:
> On 14/10/12 01:35, Valentine Barshak wrote:
>>> +$(BUILDROOT_DIR):
>>> +    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?
>
>   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
> :-)

Thanks,
probably symlinking should be done by default instead of downloading?
I'd assume that when someone does make projectdir from the BR directory,
they'd expect this particular BR do be used as the source for the new 
project.

In case of downloading, it's possible to download/copy current BR to 
another location manually (without projectdir) and build there.

Are there any obvious differences compared to using projectdir in this case?

What benefits does it give?

Thanks,
Val.
>
>   Regards,
>   Arnout
>

[Buildroot] [PATCH 12/13] target/generic: add filesystem overlay option

[Arnout Vandecappelle]

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>
---
 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] [PATCH 12/13] target/generic: add filesystem overlay option

[Danomi Manchego]

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 -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121013/7f9f53c7/attachment.html>

[Buildroot] [PATCH 12/13] target/generic: add filesystem overlay option

[Arnout Vandecappelle]

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

-- 
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
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH 12/13] target/generic: add filesystem overlay option

[Danomi Manchego]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121014/141257eb/attachment.html>

[Buildroot] [PATCH 12/13] target/generic: add filesystem overlay option

[Thomas De Schampheleire]

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 at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] [PATCH 12/13] target/generic: add filesystem overlay option

[Arnout Vandecappelle]

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
-- 
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
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH 13/13] Document BR2_PROJECT_DIR in the manual

[Arnout Vandecappelle]

From: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 docs/manual/customize-project.txt |   37 +++++++++++++++++++++++++++++++++++++
 docs/manual/customize.txt         |    2 ++
 2 files changed, 39 insertions(+)
 create mode 100644 docs/manual/customize-project.txt

diff --git a/docs/manual/customize-project.txt b/docs/manual/customize-project.txt
new file mode 100644
index 0000000..db6b757
--- /dev/null
+++ b/docs/manual/customize-project.txt
@@ -0,0 +1,37 @@
+Storing the configuration in a project directory
+------------------------------------------------
+[[project-dir]]
+
+When you use buildroot in different projects, it's a good idea to keep
+each project separate from buildroot itself.  Buildroot makes this
+possible with the +BR2_PROJECT_DIR+ option.  The project directory
+contains all the configuration files and the filesystem overlay for
+your project.
+
+After configuring buildroot, the linux kernel, etc., run the following
+command.
+
+--------------------
+make PROJECT_DIR=/path/to/project/dir projectdir
+--------------------
+
+This will create the directory +/path/to/project/dir+, which contains
+the buildroot configuration, and all other configuration files required
+to rebuild your system.
+
+To further customize your project, you can:
+
+* add a directory called +rootfs-overlay+ and fill it with additional
+  files and directories that should be installed in the root filesystem
+  (see xref:customize-rootfs[+BR2_ROOTFS_OVERLAY+]);
+
+* add a script called +post-build.sh+ to modify the root filesystem
+  (see xref:customize-rootfs[+BR2_ROOTFS_POST_BUILD_SCRIPT+]);
+
+* add a makefile +project.mk+ with additional buildroot targets.
+
+In addition, the project directory contains a Makefile to allow you to
+build directly from there.  This Makefile downloads and extracts
+buildroot, then builds everything according to your configuration. To
+avoid downloading buildroot, create a symbolic link to the buildroot
+directory in the project directory.
diff --git a/docs/manual/customize.txt b/docs/manual/customize.txt
index e8235de..86fc1fb 100644
--- a/docs/manual/customize.txt
+++ b/docs/manual/customize.txt
@@ -10,3 +10,5 @@ include::customize-uclibc-config.txt[]
 include::customize-kernel-config.txt[]
 
 include::customize-toolchain.txt[]
+
+include::customize-project.txt[]

[Buildroot] [PATCH 00/13] Add support for a project directory

[Thomas Petazzoni]

Arnout,

On Sun, 14 Oct 2012 01:13:45 +0200, Arnout Vandecappelle
\(Essensium/Mind\) wrote:
>  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).

I agree about this one.

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

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.

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

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 00/13] Add support for a project directory

[Thomas Petazzoni]

On Sun, 14 Oct 2012 10:35:18 +0200, Thomas Petazzoni wrote:

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

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 00/13] Add support for a project directory

[Arnout Vandecappelle]

On 14/10/12 10:46, Thomas Petazzoni wrote:
> On Sun, 14 Oct 2012 10:35:18 +0200, Thomas Petazzoni wrote:
>
>> 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 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.  So what
patches 1 to 7 do is nothing more than changing the defaults.

  Perhaps the name should be changed to CONFIG_DIR because it really just
contains configuration.  However, CONFIG is already pretty overloaded
(buildroot config, pkg-config, autoconf) so I don't like to use it.

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

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


>   * Custom packages are not taken into account

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

BR2_PACKAGE_FOO=y
include package/foo/foo.mk


  As I mentioned in my first mail, the setting of BR2_PACKAGE_FOO=y
could be automated, but I'm in fact not convinced that it's worth it.


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


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


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


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

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

  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
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH 00/13] Add support for a project directory

[Thomas Petazzoni]

Arnout,

On Sun, 14 Oct 2012 12:43:14 +0200, Arnout Vandecappelle wrote:

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

Come on, it's just something like:

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

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

Except that what you're proposing is almost exactly what we had at the
time, so to me it sounds like the same 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:
> 
>   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).

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

> >   * Custom packages are not taken into account
> 
>   In $(PROJECT_DIR)/project.mk, add:
> 
> BR2_PACKAGE_FOO=y
> include package/foo/foo.mk

Then you can just use the "local.mk" mechanism similarly, it already
exists.

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

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.

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

And those are the most annoying ones to maintain and upgrade when you
want to upgrade to a new Buildroot version. So basically, it seems to
me like your patch set solves problems that are already solved
(specifying a custom location of kernel config, uClibc config, kernel
patches, U-Boot patches, etc.), while it doesn't solve any of the real
problems that aren't solved today.

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

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"?

> > 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?

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

And this is all already possible:

BR2_ROOTFS_SKELETON_CUSTOM=y
BR2_ROOTFS_SKELETON_CUSTOM_PATH="$(TOPDIR)/../foo"

BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="$(TOPDIR)/../kernel.config"

etc, etc.

So, sorry, but still not convinced. But I'm not the only Buildroot
developer and user, and I'm not the maintainer. So my voice is just one
amongst many others.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 00/13] Add support for a project directory

[Arnout Vandecappelle]

On 14/10/12 14:55, Thomas Petazzoni wrote:
> Arnout,
>
> On Sun, 14 Oct 2012 12:43:14 +0200, Arnout Vandecappelle wrote:
>
>>> 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.
>
> Come on, it's just something like:
>
> 	$(TOPDIR)/../myproject/linux.config

  Except that I want the flexibility to have the buildroot tree in a different
place (e.g. a shared directory).  That said, it's still easy:

  $(MYPROJECT_DIR)/linux.config

  The issue is that it has to be filled in in many places.  I'm just trying
to make it easier.  And I'm also trying to establish a default policy,
so it's easier for users to understand how to use buildroot.

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

  As I wrote several times already, all of this can already be done with the
current infrastructure (with one exception: 'make savedefconfig' saving
to a different file than 'defconfig').  It just provides simpler defaults.

[snip]
> 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.

  Well, that documentation would be:

  - Define all the custom paths to $(PROJECT_DIR)/foo.config
  - Write a Makefile that does 'make -C <buildroot_dir> PROJECT_DIR=<project_dir>'

  And people will wonder why all those paths aren't already
$(PROJECT_DIR)/foo.config by default.


[snip]
> 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"?

  IMHO, it is.

  I could do the following: I write a section in the documentation about
how to save your customization.  This section will have two alternatives:
in-tree configuration or out-of-tree configuration.  Then I can post a
second patch that removes the parts of the out-of-tree documentation that
become unnecessary when this patch series is implemented.


>>> 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?

  Mainly because customers for some obscure reason want to use svn.


[snip]


  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
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH 00/13] Add support for a project directory

[Arnout Vandecappelle]

On 14/10/12 10:35, Thomas Petazzoni wrote:
> 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.

  Should I rename it to something else?

  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
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH 00/13] Add support for a project directory

[Thomas Petazzoni]

On Tue, 16 Oct 2012 22:03:43 +0200, Arnout Vandecappelle wrote:

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

I agree that you're not trying to share the build output between
different projects, as was the "project feature" that existed before
2009 did. That said, I still don't get the benefit of this PROJECT_DIR
thing when you can simply set you Linux configuration file, Linux
patches, U-Boot patches and so on to point to the correct location with
the existing Buildroot.

I don't see which problems it is solving, and to me, it only creates
yet another option to configure Buildroot that will only confuse
users.

But again, as I said in my earlier e-mails: this is just _my_ voice,
and I am not the only Buildroot developer or contributor, and I am not
the maintainer. So my voice is just my voice, nothing more.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 00/13] Add support for a project directory

[Sagaert Johan]

 
Hi

I have patched my 2012.02 and 2012.05 so i could enter a project name in the buildroot menuconfig.
If I was happy with everyting and did my version of saveconfig then it created a default config:

buildrootdir/configs/<projectname>_defconfig

And i also saved the kernel .config,busybox .config,and uclibc .config under board/<projectname>
This was for me convenient enough.

I think it does not make much sense to make it complicated. In practice i found out when I develop a new board I try to use the
latest version, I don't port older boards to the latest buildroot unless I need stuff that is only supported in the latest
kernels/libs etc.
So all my archived (patched) buildroot versions contain just one hw board and several rootfs variations.(different target
applications) 

( one of patches creates a symlink in the buildroot directory, so I can just refer to  buildroot/kerneldir in make module makefile,
I don't need to edit my makefiles after having selected another kernel version )

Regards Johan

-----Oorspronkelijk bericht-----
Van: buildroot-bounces at busybox.net [mailto:buildroot-bounces at busybox.net] Namens Thomas Petazzoni
Verzonden: woensdag 17 oktober 2012 19:26
Aan: Arnout Vandecappelle
CC: buildroot at busybox.net
Onderwerp: Re: [Buildroot] [PATCH 00/13] Add support for a project directory


On Tue, 16 Oct 2012 22:03:43 +0200, Arnout Vandecappelle wrote:

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

I agree that you're not trying to share the build output between different projects, as was the "project feature" that existed
before
2009 did. That said, I still don't get the benefit of this PROJECT_DIR thing when you can simply set you Linux configuration file,
Linux patches, U-Boot patches and so on to point to the correct location with the existing Buildroot.

I don't see which problems it is solving, and to me, it only creates yet another option to configure Buildroot that will only
confuse users.

But again, as I said in my earlier e-mails: this is just _my_ voice, and I am not the only Buildroot developer or contributor, and I
am not the maintainer. So my voice is just my voice, nothing more.

Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux development, consulting, training and support.
http://free-electrons.com
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] [PATCH 00/13] Add support for a project directory

[Thomas De Schampheleire]

Hi,

On Sun, Oct 14, 2012 at 1:13 AM, Arnout Vandecappelle (Essensium/Mind)
<arnout@mind.be> wrote:
>  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 :-)
>

For what it's worth, I don't think I need a PROJECT_DIR feature. I'm
using Buildroot pretty much according to the way Thomas has described
it in his 'Buildroot for real projects' presentation:
- project specific packages are placed in package/<company>/...,
- config files, post-build script, rootfs overlay, ... are placed in
board/<company>/<project>/...

I'm using standard version control system features to merge these
changes with new buildroot releases, with no real problems so far.

I do like some of the patches in this series, though, and have
commented on them individually. I'd like these to be continued
regardless of the decision on the series.

Best regards,
Thomas

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