| Message ID | 1366621622-7953-1-git-send-email-spdawson@gmail.com |
|---|---|
| State | Rejected |
| Headers | show |
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]
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.
> > 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 >
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).
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[]