Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 0/7] Introduce the _AVAILABLE mechanism
Date: Wed, 31 Oct 2012 00:11:20 +0100	[thread overview]
Message-ID: <50905E98.3080207@mind.be> (raw)
In-Reply-To: <1347234052-10527-1-git-send-email-yann.morin.1998@free.fr>

  Although we'll discuss this at the BR devel day next Saturday, Yann won't be there
so we'd better have some discussion on the list as well (unless, Yann, you could
be available on chat?).

On 09/10/12 01:40, Yann E. MORIN wrote:
[snip]
> On the other hand, Arnout pointed out that only packages with depenencies on
> toolchain features should be converted, and in cascade, packages that depend
> on those, leaving alone packages that do not have any depednency at all (if
> I understood correctly):
>      http://lists.busybox.net/pipermail/buildroot/2012-August/058040.html
>
> Of course, no need to say I'm in favor of modifying all packages, if at least
> only for points 1&2 above. ;-) Of course, I understand Arnout's concerns about
> keeping simplicity and not adding cruft where it is not needed. This post is
> to request comments on this new deeply-impacting change.

  With the pkg-new script, my concern is much reduced.  The simplicity of having
the same pattern all over wins out in that case.

[snip]
> Again, this series is an _RFC_ on the _AVAILABLE mechanism, so the first
> question we must answer is:
>
>      Do we even want this mechanism in buildroot at all?
>
> Then, and only then, can we decide what to do, and how far to push it.

  There is still an alternative: patch Kconfig to "properly" handle
select/depend transitivity.  I.e., when a symbol selects another symbol,
this implies that all dependencies of the other symbol are inherited.  Did
anyone ever investigate the feasibility of such an feature?

  Regards,
  Arnout

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
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

  parent reply	other threads:[~2012-10-30 23:11 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-09 23:40 [Buildroot] [PATCH 0/7] Introduce the _AVAILABLE mechanism Yann E. MORIN
2012-09-09 23:40 ` [Buildroot] [PATCH 1/7] docs/manual: update 'adding packages' with the new _AVAILABLE symbol Yann E. MORIN
2012-11-01  1:30   ` Arnout Vandecappelle
2012-11-01 16:21     ` Yann E. MORIN
2012-11-01 22:40       ` Arnout Vandecappelle
2012-11-02  8:59         ` Thomas Petazzoni
2012-09-09 23:40 ` [Buildroot] [PATCH 2/7] support/scripts: add a script to add a new package Yann E. MORIN
2012-10-14 11:14   ` [Buildroot] [PATCH] pkg-avail: make it work without stgit Thomas Petazzoni
2012-10-14 12:03     ` Baruch Siach
2012-10-14 12:12       ` Yann E. MORIN
2012-10-14 13:33     ` Yann E. MORIN
2012-10-14 13:52       ` Thomas Petazzoni
2012-11-01  2:00   ` [Buildroot] [PATCH 2/7] support/scripts: add a script to add a new package Arnout Vandecappelle
2012-11-01  9:09     ` Thomas Petazzoni
2012-11-01 17:00       ` Yann E. MORIN
2012-11-01 16:56     ` Yann E. MORIN
2012-11-01 17:25     ` Yann E. MORIN
2012-09-09 23:40 ` [Buildroot] [PATCH 3/7] support/scripts: add a script to automate the migration to _AVAILABLE Yann E. MORIN
2012-09-09 23:40 ` [Buildroot] [PATCH 4/7] packages: introduce the _AVAILABLE symbol to all packages Yann E. MORIN
2012-09-09 23:40 ` [Buildroot] [PATCH 5/7] packages: use the newly-introduced _AVAILABLE symbol Yann E. MORIN
2012-09-09 23:40 ` [Buildroot] [PATCH 6/7] packages: check proper use of 'select' against packages Yann E. MORIN
2012-09-09 23:40 ` [Buildroot] [PATCH 7/7] script/support: get rid of now-useless pkg-avail script Yann E. MORIN
2012-09-09 23:45 ` [Buildroot] [PATCH 0/7] Introduce the _AVAILABLE mechanism Yann E. MORIN
2012-09-10  6:51   ` Peter Korsgaard
2012-10-14 10:53 ` Thomas Petazzoni
2012-10-14 14:05 ` Thomas Petazzoni
2012-10-14 14:31   ` Yann E. MORIN
2012-10-14 17:38     ` Thomas Petazzoni
2012-10-16  5:39       ` Arnout Vandecappelle
2012-10-16 17:34         ` Yann E. MORIN
2012-10-17 21:33           ` Arnout Vandecappelle
2012-10-17 19:30         ` Thomas Petazzoni
2012-10-17 19:47           ` Yann E. MORIN
2012-10-17 20:05             ` Thomas Petazzoni
2012-10-17 20:16               ` Yann E. MORIN
2012-10-17 20:41                 ` Thomas Petazzoni
2012-10-17 20:48                   ` Arnout Vandecappelle
2012-10-30 23:11 ` Arnout Vandecappelle [this message]
2012-10-30 23:35   ` Yann E. MORIN
2012-10-30 23:44     ` Yann E. MORIN
2012-10-30 23:48     ` Arnout Vandecappelle
2012-10-30 23:58       ` Yann E. MORIN

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=50905E98.3080207@mind.be \
    --to=arnout@mind.be \
    --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