Patchwork [RFC] permit menu customization

login
register
mail settings
Submitter Simon Dawson
Date April 22, 2013, 9:07 a.m.
Message ID <1366621622-7953-1-git-send-email-spdawson@gmail.com>
Download mbox | patch
Permalink /patch/238366/
State Rejected
Headers show

Comments

Simon Dawson - April 22, 2013, 9:07 a.m.
From: Simon Dawson <spdawson@gmail.com>

This patch is a first attempt at providing a mechanism by which the user
can specify a local menu configuration file, for extending the Buildroot
menu system.

The main use case I have in mind is the selection and configuration of
local packages.

One problem with what is proposed here is that it is necessary to
"bootstrap" the system by providing an empty Config.in.user file; ideally,
this file should be touched somewhere in the top-level Makefile, and added
to .gitignore, as it is really a build artefact.

Signed-off-by: Simon Dawson <spdawson@gmail.com>
---
 Config.in                      |    9 +++++++++
 Makefile                       |   20 ++++++++++++++++++++
 docs/manual/customize-menu.txt |   16 ++++++++++++++++
 docs/manual/customize.txt      |    2 ++
 4 files changed, 47 insertions(+)
 create mode 100644 Config.in.user
 create mode 100644 docs/manual/customize-menu.txt
Arnout Vandecappelle - April 22, 2013, 9:24 p.m.
Hi Simon,


On 22/04/13 11:07, spdawson@gmail.com wrote:
> From: Simon Dawson<spdawson@gmail.com>
>
> This patch is a first attempt at providing a mechanism by which the user
> can specify a local menu configuration file, for extending the Buildroot
> menu system.

  A couple of patches with a similar purpose have been posted in the last 
year or so. However, at the last two buildroot developer meetings we've 
decided that this approach is not the way we want to go. Instead, adding 
custom packages should be done by including them directly at the top of 
packages/Config.in.


> The main use case I have in mind is the selection and configuration of
> local packages.
>
> One problem with what is proposed here is that it is necessary to
> "bootstrap" the system by providing an empty Config.in.user file; ideally,
> this file should be touched somewhere in the top-level Makefile, and added
> to .gitignore, as it is really a build artefact.

  Another buildroot rule is that the build should never modify the 
buildroot directory itself when O= is specified on the command line. So 
the Config.in.user should at least be in the CONFIG_DIR rather than the 
TOPDIR.


  Regards,
  Arnout

[snip]
Simon Dawson - April 23, 2013, 7:14 a.m.
Hi Arnout; thanks for taking the time to look at this.

On 22 April 2013 22:24, Arnout Vandecappelle <arnout@mind.be> wrote:
>  A couple of patches with a similar purpose have been posted in the last
> year or so. However, at the last two buildroot developer meetings we've
> decided that this approach is not the way we want to go. Instead, adding
> custom packages should be done by including them directly at the top of
> packages/Config.in.

This seems like a missed opportunity to me --- especially when we can so easily
hook the configuration menu for user customization. It would be nice if local
packages could be added without having to edit buildroot itself. Do you --- or
others --- think that there is any point in pursuing this idea? The
fact that similar
patches have been proposed before would seem to suggest that this is something
that users would benefit from.

>  Another buildroot rule is that the build should never modify the buildroot
> directory itself when O= is specified on the command line. So the
> Config.in.user should at least be in the CONFIG_DIR rather than the TOPDIR.

Okay; thanks for the tip. I'll fix it if this patch survives into
another iteration.

Simon.
Jeremy Rosen - April 23, 2013, 7:18 a.m.
> 
> On 22/04/13 11:07, spdawson@gmail.com wrote:
> > From: Simon Dawson<spdawson@gmail.com>
> >
> > This patch is a first attempt at providing a mechanism by which the
> > user
> > can specify a local menu configuration file, for extending the
> > Buildroot
> > menu system.
> 
>   A couple of patches with a similar purpose have been posted in the
>   last
> year or so. However, at the last two buildroot developer meetings
> we've
> decided that this approach is not the way we want to go. Instead,
> adding
> custom packages should be done by including them directly at the top
> of
> packages/Config.in.
> 


So, basically, it's not possible to add a software to buildroot without
modifying buildroot-provided files... 

I know I wasn't at these dev meetings, but when we work for customers that
develop dedicated software for their appliance I can't use the simple
rule "every change in the buildroot tree should be upstreamed"

it also means that generating patches in a tree like that (mixture of
upstreamable and non-upstreamable changes) is more complicated. 

I can mange that but I know for a fact that lots of customers won't bother 
with that... And I can't always do it for them.

I have been working on some time on finding a way of having a work
environement for buildroot that I can provide which clearly separates

* buildroot provided files
* local configuration
* the local single-purpose software for the project

but I can't really manage to do it. O= helps, it allows to separate (most of)
the configuration, the XXX_OVERRIDE_SRCDIR also helps managing hevily 
patched dependencies (where we would upstream to the project but not to
buildroot)

but managing buildroot-upstreamable changes is a bit complicated because I 
have to edit packages/Config.in and packages/Makefile.in

I would really appreciate a patch as above (I tried to write it myself but
also stumbled on the seeding problem) so, for what it's worth, I'll second it

I know the official answer is "a project <=> a board" and that I should copy
the defconfig into a new board, but that seems weird when I am reusing an 
existing board and, again, it complicates configuration management. 

Basically my whole project has to be a clone of buildroot, whereas I would 
like buildroot to be a submodule of my project so I can keep my changes 
separated.


comments would be appreciated on how to do that....

> 
>   Another buildroot rule is that the build should never modify the
> buildroot directory itself when O= is specified on the command line.
> So
> the Config.in.user should at least be in the CONFIG_DIR rather than
> the
> TOPDIR.
> 

on a (slightly) related note, should I re-send my patch that changes the
default location of local.mk to $(CONFIG_DIR) instead of $(TOPDIR) ?

> 
>   Regards,
>   Arnout
> 
> [snip]
> 
> --
> Arnout Vandecappelle                          arnout at mind be
> Senior Embedded Software Architect            +32-16-286500
> Essensium/Mind                                http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR
> Leuven
> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
> _______________________________________________
> buildroot mailing list
> buildroot@busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
Reuben Dowle - April 23, 2013, 9:09 p.m.
I think a change like this would be quite useful. I have to maintain a set of buildroot packages which are project specific, and it would on the surface seem like a better solution if these additions could be kept separate to the build root files where changes can be upstreamed.

Regards,
Reuben

> -----Original Message-----
> From: buildroot-bounces@busybox.net [mailto:buildroot-
> bounces@busybox.net] On Behalf Of Jeremy Rosen
> Sent: Tuesday, 23 April 2013 7:19 p.m.
> To: Arnout Vandecappelle
> Cc: buildroot@busybox.net
> Subject: Re: [Buildroot] [RFC] permit menu customization
>
> >
> > On 22/04/13 11:07, spdawson@gmail.com wrote:
> > > From: Simon Dawson<spdawson@gmail.com>
> > >
> > > This patch is a first attempt at providing a mechanism by which the
> > > user
> > > can specify a local menu configuration file, for extending the
> > > Buildroot
> > > menu system.
> >
> >   A couple of patches with a similar purpose have been posted in the
> >   last
> > year or so. However, at the last two buildroot developer meetings
> > we've
> > decided that this approach is not the way we want to go. Instead,
> > adding
> > custom packages should be done by including them directly at the top
> > of
> > packages/Config.in.
> >
>
>
> So, basically, it's not possible to add a software to buildroot without
> modifying buildroot-provided files...
>
> I know I wasn't at these dev meetings, but when we work for customers
> that
> develop dedicated software for their appliance I can't use the simple
> rule "every change in the buildroot tree should be upstreamed"
>
> it also means that generating patches in a tree like that (mixture of
> upstreamable and non-upstreamable changes) is more complicated.
>
> I can mange that but I know for a fact that lots of customers won't
> bother
> with that... And I can't always do it for them.
>
> I have been working on some time on finding a way of having a work
> environement for buildroot that I can provide which clearly separates
>
> * buildroot provided files
> * local configuration
> * the local single-purpose software for the project
>
> but I can't really manage to do it. O= helps, it allows to separate
> (most of)
> the configuration, the XXX_OVERRIDE_SRCDIR also helps managing hevily
> patched dependencies (where we would upstream to the project but not to
> buildroot)
>
> but managing buildroot-upstreamable changes is a bit complicated
> because I
> have to edit packages/Config.in and packages/Makefile.in
>
> I would really appreciate a patch as above (I tried to write it myself
> but
> also stumbled on the seeding problem) so, for what it's worth, I'll
> second it
>
> I know the official answer is "a project <=> a board" and that I should
> copy
> the defconfig into a new board, but that seems weird when I am reusing
> an
> existing board and, again, it complicates configuration management.
>
> Basically my whole project has to be a clone of buildroot, whereas I
> would
> like buildroot to be a submodule of my project so I can keep my changes
> separated.
>
>
> comments would be appreciated on how to do that....
>
> >
> >   Another buildroot rule is that the build should never modify the
> > buildroot directory itself when O= is specified on the command line.
> > So
> > the Config.in.user should at least be in the CONFIG_DIR rather than
> > the
> > TOPDIR.
> >
>
> on a (slightly) related note, should I re-send my patch that changes
> the
> default location of local.mk to $(CONFIG_DIR) instead of $(TOPDIR) ?
>
> >
> >   Regards,
> >   Arnout
> >
> > [snip]
> >
> > --
> > Arnout Vandecappelle                          arnout at mind be
> > Senior Embedded Software Architect            +32-16-286500
> > Essensium/Mind                                http://www.mind.be
> > G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR
> > Leuven
> > LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> > GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
> > _______________________________________________
> > buildroot mailing list
> > buildroot@busybox.net
> > http://lists.busybox.net/mailman/listinfo/buildroot
> >
> _______________________________________________
> buildroot mailing list
> buildroot@busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it).

Patch

diff --git a/Config.in b/Config.in
index bbb9885..7b92d67 100644
--- a/Config.in
+++ b/Config.in
@@ -437,6 +437,13 @@  config BR2_PACKAGE_OVERRIDE_FILE
 	  as the source directory for a particular package. See the
 	  Buildroot documentation for more details on this feature.
 
+config BR2_LOCAL_MENUCONFIG_FILE
+	string "location of a local menu configuration file"
+	default "$(TOPDIR)/Config.in.local"
+	help
+	  A local menu configuration file can be used to add custom
+	  entries to the Buildroot configuration menu.
+
 config BR2_GLOBAL_PATCH_DIR
 	string "global patch directory"
 	help
@@ -469,3 +476,5 @@  source "boot/Config.in"
 source "linux/Config.in"
 
 source "Config.in.legacy"
+
+source "Config.in.user"
diff --git a/Config.in.user b/Config.in.user
new file mode 100644
index 0000000..e69de29
diff --git a/Makefile b/Makefile
index 0a91658..2235403 100644
--- a/Makefile
+++ b/Makefile
@@ -711,6 +711,26 @@  savedefconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile
 		--savedefconfig=$(if $(DEFCONFIG),$(DEFCONFIG),$(CONFIG_DIR)/defconfig) \
 		$(CONFIG_CONFIG_IN)
 
+# Update the user menu configuration file
+.PHONY: update-user-config
+menuconfig nconfig gconfig xconfig config oldconfig randconfig allyesconfig allnoconfig silentoldconfig release randpackageconfig allyespackageconfig allnopackageconfig source-check print-version olddefconfig: update-user-config
+%_defconfig: update-user-config
+CONFIG_USER_IN=Config.in.user
+CONFIG_LOCAL_IN:=$(shell grep -E '^BR2_LOCAL_MENUCONFIG_FILE=' $(BUILDROOT_CONFIG) | sed -r -e 's/^BR2_LOCAL_MENUCONFIG_FILE=\"//' -e 's/\"$$//' -e 's,\$$\(TOPDIR\),$(TOPDIR),g')
+update-user-config: $(CONFIG_USER_IN)
+	@echo "# Buildroot auto-generated file: DO NOT EDIT" >$<
+ifeq ($(CONFIG_LOCAL_IN),)
+	@echo "# No user menu configuration file specified" >>$<
+else
+	$(call MESSAGE,"Updating user configuration file")
+	@if test -e $(CONFIG_LOCAL_IN); then \
+		echo "# User menu configuration" >>$< ; \
+		echo "source \"$(CONFIG_LOCAL_IN)\"" >>$< ; \
+	else \
+		echo "# User menu configuration file does not exist: $(CONFIG_LOCAL_IN)" >>$<; \
+	fi
+endif
+
 # check if download URLs are outdated
 source-check:
 	$(MAKE) DL_MODE=SOURCE_CHECK $(EXTRAMAKEARGS) source
diff --git a/docs/manual/customize-menu.txt b/docs/manual/customize-menu.txt
new file mode 100644
index 0000000..f4825b7
--- /dev/null
+++ b/docs/manual/customize-menu.txt
@@ -0,0 +1,16 @@ 
+// -*- mode:doc -*- ;
+
+[[menu-custom]]
+Customizing the menu
+~~~~~~~~~~~~~~~~~~~~
+
+A local menu configuration file can be used to add custom entries to the
+Buildroot configuration menu.
+
+The +BR2_LOCAL_MENUCONFIG_FILE+ configuration file option can be
+used to specify the location of a local menu configuration file.
+
+A knowledge of the Kconfig configuration language syntax will be required
+in order to write a local menu configuration file. The documentation for this
+syntax is available at
+http://kernel.org/doc/Documentation/kbuild/kconfig-language.txt[]
diff --git a/docs/manual/customize.txt b/docs/manual/customize.txt
index 0456ef1..61cb9fa 100644
--- a/docs/manual/customize.txt
+++ b/docs/manual/customize.txt
@@ -17,3 +17,5 @@  include::customize-toolchain.txt[]
 include::customize-store.txt[]
 
 include::customize-packages.txt[]
+
+include::customize-menu.txt[]