[Buildroot] [RFC] permit menu customization

[Jeremy Rosen <jeremy.rosen@openwide.fr>]

> 
> On 22/04/13 11:07, spdawson at 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 at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>