From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 0/7] Introduce the _AVAILABLE mechanism
Date: Tue, 16 Oct 2012 07:39:52 +0200 [thread overview]
Message-ID: <507CF328.5090505@mind.be> (raw)
In-Reply-To: <20121014193849.019347dd@skate>
On 14/10/12 19:38, Thomas Petazzoni wrote:
> In other words: we can assume the user knows about big subsystems
> (X.org, Python, Perl, etc.), but we don't want him to know the fine
> details of the dependencies on sub-options.
Someone (I don't remember who) proposed to stop doing that, because it adds
little value. Indeed, it's not as if 9 extra entries in the Scripting
Languages menu will suddenly make it more difficult to navigate. Maybe X.org
is an exception, but even there most packages are collected in the x11r7 menus
(and those could still be kept in a conditional).
Originally I was in favour of having the BR2_PACKAGE_PYTHON conditionals,
but it _would_ probably make life simpler if we only had dependencies on
toolchain options...
Yann, what do you think, would it make suboption handling simpler if there
was no 'depends on BR2_PACKAGE_PYTHON'?
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
next prev parent reply other threads:[~2012-10-16 5:39 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 [this message]
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
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=507CF328.5090505@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