intro
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 2 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 2 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [Buildroot] [PATCH 0/2] intro
I just sent a new patch
[PATCH 1/1] kconfig: Add a configuration subtree command to kconfig that splits the execute and subtree patch. The "subsource" tag is activated by "-s" option to mconfig,qconfig, nconfig and gconfig now.
Quoted 3 lines · Arnout Vandecappelle
Hoi,
I'm not very enthousiastic about either of these two features.
subtrees are for convenience only. Still everything can be done the way it is now.
Quoted 11 lines · On Thursday 17 November 2011 14:18:07 Konrad Eisele wrote:
Quoted 9 lines
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 8 lines
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
Kconfigcan deal with such huge configurations.
I have added rudiment support so that you can specify
subsource "kconfig.in" "path" "$(var)/config" ...
where "$(var) is substituted by the symbol-value of "var". I did it only for the ".config" entry of "subsource" but it acn be done
for "kconfig.in" element as well, i.e. you could
subsource "linux-$(lversion)/arch/$(arch)/kconfig.in" "path" "$(var)/config" ... The function to use is resolve_vars() in support/kconfig/util.c of the patch.
Quoted 3 lines
- I don't like the size explosion of the buildroot tree that we would see if all these configs are included.
You could define a subtree that point to the kconfig root of the package _after_ download and install. Then you can add a check weather a subtree exists by adding support/kconfig/zconf.y:
/* subsource $2:"sub-kconfig" $3:"sub-chdir" $4:"sub-.config" $5:"Title" $6:"subdomainprefix" $7:"confprefix" */subsource_stmt: T_SUBSOURCE prompt prompt prompt prompt T_WORD word_opt T_EOL
{
if (dosubsource) {
+ FILE *f = zconf_fopen($2);
+ if (f) {
+ fclose(f);
printd(DEBUG_PARSE, "%s:%d:subsource %s\n", zconf_curname(), zconf_lineno(), $2);
zconf_nextconf($2, $3, $4, $5, $6, $7);
+ }
}
}If the subtree doesnt exists the statement is ignored...
Quoted 11 lines
- 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'.
Can still be done.
Quoted 5 lines
- I don't know what it will look like visually because the patch failed to compile for me (
current_conf_levelis 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.
please try the patch I sent a hour ago to the list.
[PATCH 1/1] kconfig: Add a configuration subtree command to kconfig It also includes the bison, flex, gperf outputs. it is diffed against master of one hour ago...
Quoted 8 lines
Quoted 7 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 4 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 :-)
Still, you have to exit. Running it with a press on a button is more intuitive... -- Konrad
Quoted 6 lines
Regards,
Arnout