intro

Quoted 49 lines · Arnout Vandecappelle

Hoi,

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

Quoted 9 lines · 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

Quoted 3 lines

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.

Quoted 5 lines

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.

Quoted 5 lines

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 :-)

In fact, similar features (e.g. including one menuconfig into another) were discussed in the context of crosstool-ng integration into buildroot. See the thread "Report from the Buildroot Developer Day" and Yann's comments on it.

There are two ways to do a better integration:

1) Include the crosstool-NG menuconfig entries into the buildroot menuconfig. This will be difficule for two reasons:
- namespace clashing [1]

- maintenance when a newer crosstool-NG version gets integrated

Best regards,
Thomas