Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] Adding in support for custom configurations
Date: Mon, 18 Apr 2016 21:15:58 +0200	[thread overview]
Message-ID: <20160418211558.12db7fdf@free-electrons.com> (raw)
In-Reply-To: <20160418162528.GA5827@asimov.austin.ibm.com>

Hello,

On Mon, 18 Apr 2016 11:25:28 -0500, Patrick Williams wrote:

> 1. Have support for a defconfig location other than
> $(BR2_EXTERNAL)/configs/.
> 
>     We have the proposed patchset, which is too specific due to the use
>     of 'custom', and we have a local hack where we put the same recipe
>     into $(BR2_EXTERNAL)/docs/custom/custom.mk.  Other than docs/*/*.mk,
>     there is no include in buildroot/Makefile into the BR2_EXTERNAL tree
>     when invoked without an existing .config.
> 
>     Would there be opposition to a new -include in buildroot/Makefile
>     outside of the large $(if BR2_HAVE_DOT_CONFIG... block into the
>     BR2_EXTERNAL tree?  This would give us a hook point to add the
>     %_defconfig recipe found in this patchset.
> 
>     Alternatively, or additionally, we could create a
>     BR2_EXTERNAL_CONFIGS variable as a set of additional directories to
>     search as defconfig locations.
> 
> 2. (Bonus) Enhance list-defconfigs to also display the defconfigs found
> at this extra location.
> 
>     Would there be opposition to something like a
>     $(BR2_LIST_DEFCONFIGS_CMDS) variable to extend the list-defconfigs
>     in the custom tree?

I think the only reasonable solution to this is to really allow
multiple BR2_EXTERNAL directories. A patch series doing this was
proposed by Yann E. Morin a while ago, but due to the fairly
significant additional complexity, it hasn't been merged so far.

Maybe hearing your use case will help push the feature further, or will
encourage other folks in the Buildroot community to come up with
alternate solutions for your problem.

One question that immediately comes to mind is: why do you maintain a
BR2_EXTERNAL tree on your side? If all you do is related to publicly
available machines/packages, why don't you upstream all what you have
in Buildroot, and let only your downstream users that need to create
private/confidential things use the BR2_EXTERNAL feature?

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

  parent reply	other threads:[~2016-04-18 19:15 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-15 15:40 [Buildroot] [PATCH] Adding in support for custom configurations Patrick Williams
2016-04-16  1:06 ` Steve Calfee
2016-04-17 20:31 ` Thomas Petazzoni
2016-04-18 16:25   ` Patrick Williams
2016-04-18 17:07     ` Steve Calfee
2016-04-18 17:14       ` Patrick Williams
2016-04-18 17:37         ` Steve Calfee
2016-04-18 20:59           ` Patrick Williams
2016-04-18 19:15     ` Thomas Petazzoni [this message]
2016-04-18 21:44       ` Patrick Williams
2016-04-18 23:57         ` Arnout Vandecappelle
2016-04-19  7:22           ` Thomas Petazzoni
2016-05-12  2:12 ` [Buildroot] [PATCH] Support nested config directories Patrick Williams
2016-05-12 13:55   ` Thomas Petazzoni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160418211558.12db7fdf@free-electrons.com \
    --to=thomas.petazzoni@free-electrons.com \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox