[Buildroot] [PATCH v3 2/6] Add documentation for merged defconfigs

[Patrick Williams <patrick@stwcx.xyz>]

On Wed, Jul 06, 2016 at 08:13:43AM +1000, Samuel Mendoza-Jonas wrote:
> On Tue, 2016-07-05 at 14:32 -0500, Patrick Williams wrote:
> > On Fri, Jul 01, 2016 at 03:18:58PM +0200, Romain Naour wrote:
> > > Hi Sam,
> > > 
> > > This series has been discussed with other developers and we concluded that this
> > > feature is not the responsibility of Buildroot to generate a defconfig from
> > > partial configuration files.
> > > 
> > > Instead we recommend to use merge_config.sh from outside of Buildroot to
> > > generate the merged defconfig before calling make. Maybe we should add some
> > > documentation in the manual to explain how to use it.
> > > 
> > > Best regards,
> > > Romain
> > > 
> > 
> > Earlier we had two independent patch sets that we were asked to merge.
> > 
> >    1) Merged defconfigs (now this patch set).
> >    2) Subdirs for defconfigs.
> > 
> > If #1 has been rejected as undesireable, should we now prepare an
> > indepenent patch set for #2 or is that also not wanted now?
> > 
> > There is currently no way for us to manage this behavior in a
> > BR2_EXTERNAL layer alone because there is no Makefile from the
> > BR2_EXTERNAL path sourced in the defconfig case.  Is there any issue
> > with a patch that will source a file like $(BR2_EXTERNAL)/external-defconfig.mk?
> 
> Actually there might be - Sam was telling me yesterday that the main
> Makefile includes?$(BR2_EXTERNAL)/external.mk, which is something we may
> use to get mergeconfigs in op-build. That might work for nested configs
> as well.
> 

I've already been down this route.  The 'include
$(BR2_EXTERNAL)/external.mk' is inside a big 'ifeq
($(BR2_HAVE_DOT_CONFIG),y)' on line 336.  That effectively means if you
don't already have a .config (which comes about from running a
'defconfig' recipe) then you don't get a source to external.mk.  That is
why I'm asking about a new 'external-defconfig.mk'.

> > 
> > I realize we could have a new script, but we already have users that are
> > use to 'make <system>_defconfig && make' so we would like to be able to
> > preserve that behavior even though we are moving to merged defconfig
> > fragments.
> > 
> 

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20160705/d32d6c33/attachment.asc>