All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 0/2] intro
Date: Thu, 17 Nov 2011 23:36:18 +0000	[thread overview]
Message-ID: <201111172336.18958.arnout@mind.be> (raw)
In-Reply-To: <1321539489-19737-1-git-send-email-konrad@gaisler.com>

 Hoi,

 I'm not very enthousiastic about either of these two features.

On Thursday 17 November 2011 14:18:07 Konrad Eisele wrote:
> The aim of patch-1 is to make it possible to have configuration subtrees.
> This makes it possible to have a structure like this:
> 
> buildroot-kconfigs
> + linux-kconfigs
> + busybox-kconfigs
> + uclibc-kconfigs
> + crosstools-kconfigs
> 
> Where all configuration appear in one xconfig screen. Currently I have focues on
> qconfig only, I think however adding support for gconfig and mconfig is possible
> easily. The subtree feature is enabled with the -s option to qconfig: "qconfig -s <kconf>"

- The subtree that has to be included depends on your buildroot configuration. 
So you have to include all possible linux, busybox, uclibc, ... configs and
protect them with IFs.  I can hardly imagine that Kconfig can deal with such 
huge configurations.

- I don't like the size explosion of the buildroot tree that we would see
if all these configs are included.

- The packages which have kconfigs are the ones that are most likely to need 
board-specific modifications, which may define additional config options.  This
means that copying the config tree into buildroot isn't going to cut it.

- Running configs for these things is a bit of an expert step.  In particular
because the configs have to be post-processed by buildroot and because
you have to save them explicitly afterwards in a place different from the 
output directory.  I think that part should be smoothed out first.  Until
then, I consider it a good thing that the normal user runs 'make xconfig' 
while the expert user runs 'make {,linux-,busybox-}menuconfig'.

- I don't know what it will look like visually because the patch failed to
compile for me (current_conf_level is undefined), but I wonder if there is a
significant advantage compared to just menus.  At least in menuconfig
it wouldn't really make a difference.


> The other feature that patch-1 adds is a config-entry type "execute: It is
> like a string, however when doubleclicking (trying to edit) in qconfig
> (only in qconfig currently) then the string is executed using "system(<str>)".
> The goal is to be able to execute "make" from inside the gui, without having
> to exit.

 Here I simply don't see the benefit.  Whatever needs to be executed there
can just be done with the normal make after the config finishes.  If people
want to push a button to run make, give them Eclipse with a buildroot
plugin :-)


 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:  31BB CF53 8660 6F88 345D  54CC A836 5879 20D7 CF43

  parent reply	other threads:[~2011-11-17 23:36 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-17 14:18 [Buildroot] [PATCH 0/2] intro Konrad Eisele
2011-11-17 14:18 ` [Buildroot] [PATCH 1/2] Add a configuration subtree and an execution command to kconfig: Konrad Eisele
2011-11-17 14:18 ` [Buildroot] [PATCH 2/2] Example of how to define a subtree using kconfig tag "subsource": package/busybox/busybox-1.19.x.in is a flattend version of busybox-1.19.3's kconfig scripts (all-in-one). package/busybox/Config.in adds this Kconfig as a subtree to the main configuration tree: subsource "package/busybox/busybox-1.19.x.in" "package/busybox/" "package/busybox/busybox-1.19.x.config" "Busybox 1.19.x configuration" BUSYBOX_ CONFIG_ package/busybox/busybox-1.19.x.config is used as the .config for this subtree. config BR2_BUSYBOX_VERSION_1_19_X has to be selected for the subtree to show up Konrad Eisele
2011-11-17 14:20 ` [Buildroot] [PATCH 1/2] Add a configuration subtree and an execution command to kconfig: Konrad Eisele
2011-11-17 20:09   ` Thomas De Schampheleire
2011-11-18  7:42     ` [Buildroot] [PATCH 1/1] kconfig: Add a configuration subtree command to kconfig Konrad Eisele
2011-11-18  7:49       ` Konrad Eisele
2011-11-18  9:04     ` [Buildroot] [PATCH 1/1] kconfig: Add "execute" config-type Konrad Eisele
2011-11-17 23:36 ` Arnout Vandecappelle [this message]
2011-11-18  9:30   ` [Buildroot] [PATCH 0/2] intro Konrad Eisele
2011-11-18  9:38   ` Thomas De Schampheleire
2011-11-18 10:39     ` Konrad Eisele
2011-11-18 10:46     ` Konrad Eisele

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=201111172336.18958.arnout@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 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.