All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v5 06/13] configs: add autobuild toolchain defconfigs
Date: Thu, 6 Apr 2017 21:55:46 +0200	[thread overview]
Message-ID: <20170406215546.6e0b393d@free-electrons.com> (raw)
In-Reply-To: <20170406181854.5242-6-arnout@mind.be>

Hello,

On Thu, 6 Apr 2017 20:18:46 +0200, Arnout Vandecappelle
(Essensium/Mind) wrote:

> Note: I choose to name them xxx_defconfig and put them under to configs
> directory so they can be used directly as a quick way to set up a build
> with an external toolchain. However, neither test-pkg nor autobuild-run
> will use them as _defconfig, so we could just as well call them *.config
> and put them under e.g. support/autobuild-toolchains. Let me know what
> you think.

It's not a fully clear-cut opinion, but I believe I have a preference
for having those in support/<something>/ rather than as official
defconfigs.

I don't think it makes much sense to advertise them as defconfigs.
Those base configurations are very specialized, some of them use
completely stupid toolchain configurations (ARM no thread, really?)
that only exist for the sake of testing various combinations of
toolchain features. So making those visible to random users along with
real defconfigs for boards doesn't seem like a good idea.

Plus it avoids the need to support defconfigs in subfolders (even
though I guess you went through great lengths to workaround make
stupidity about how patterns without slashes are handled), and the big
question of your last RFC patch on how to display them in
"list-defconfigs".

Best regards,

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

  reply	other threads:[~2017-04-06 19:55 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-06 18:18 [Buildroot] [PATCH v5 00/13] support/test-pkg: fixes and enhancements + add autobuild defconfigs Arnout Vandecappelle
2017-04-06 18:18 ` [Buildroot] [PATCH v5 01/13] docs/manual: document the test-pkg script Arnout Vandecappelle
2017-04-06 19:51   ` Thomas Petazzoni
2017-04-06 18:18 ` [Buildroot] [PATCH v5 02/13] support/test-pkg: print number of toolchains and progress Arnout Vandecappelle
2017-04-06 19:51   ` Thomas Petazzoni
2017-04-06 18:18 ` [Buildroot] [PATCH v5 03/13] support/test-pkg: calculate toolchain name only once Arnout Vandecappelle
2017-04-06 20:51   ` Yann E. MORIN
2017-04-07 10:35     ` Arnout Vandecappelle
2017-04-06 18:18 ` [Buildroot] [PATCH v5 04/13] support/test-pkg: run legal-info Arnout Vandecappelle
2017-04-06 18:18 ` [Buildroot] [PATCH v5 05/13] Makefile: support defconfigs in subdirectories Arnout Vandecappelle
2017-04-06 18:18 ` [Buildroot] [PATCH v5 06/13] configs: add autobuild toolchain defconfigs Arnout Vandecappelle
2017-04-06 19:55   ` Thomas Petazzoni [this message]
2017-04-06 20:39     ` Arnout Vandecappelle
2017-04-06 18:18 ` [Buildroot] [PATCH v5 07/13] support/test-pkg: move minimal.config into a separate file Arnout Vandecappelle
2017-04-06 18:18 ` [Buildroot] [PATCH v5 08/13] support/test-pkg: get configs from buildroot defconfigs Arnout Vandecappelle
2017-04-06 19:37   ` Thomas Petazzoni
2017-04-06 20:48     ` Yann E. MORIN
2017-04-06 20:50       ` Thomas Petazzoni
2017-04-07 10:35         ` Arnout Vandecappelle
2017-04-07 10:44           ` Thomas Petazzoni
2017-04-06 18:18 ` [Buildroot] [PATCH v5 09/13] support/test-pkg: add option to use an alternate toolchain directory Arnout Vandecappelle
2017-04-06 18:18 ` [Buildroot] [PATCH v5 10/13] Makefile: refactor *config targets Arnout Vandecappelle
2017-04-06 18:18 ` [Buildroot] [PATCH v5 11/13] Makefile: add alldefconfig target Arnout Vandecappelle
2017-04-06 18:18 ` [Buildroot] [PATCH v5 12/13] support/test-pkg: use merge_config.sh to merge the fragments Arnout Vandecappelle
2017-04-06 18:18 ` [Buildroot] [PATCH v5 13/13] [RFC] list-defconfigs: support defconfigs in subdirectories Arnout Vandecappelle

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=20170406215546.6e0b393d@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.