make kconfig help is difficult to understand

[SebastianBoe]

Hi,

I found it difficult to understand what the targets in
make kconfig-help
were doing, and suspect others will find it so as well.

The documentation of this CLI, or maybe even the CLI itself, should be improved
so that it is easy for users to understand how they can interact with Kconfig.

This is the current help text:

sebo@mach:~/zephyr/samples/bluetooth/beacon$ make kconfig-help
make[1]: Entering directory '/home/sebo/zephyr'
make[2]: Entering directory '/home/sebo/zephyr/samples/bluetooth/beacon/outdir/nrf51_pca10028'
Configuration targets:

  config	  - Update current config utilising a line-oriented program
  nconfig         - Update current config utilising a ncurses menu based program
  menuconfig	  - Update current config utilising a menu based program
  xconfig	  - Update current config utilising a QT based front-end
  gconfig	  - Update current config utilising a GTK based front-end
  oldconfig	  - Update current config utilising a provided .config as base
  silentoldconfig - Same as oldconfig, but quietly, additionally update deps
  defconfig	  - New config with default from ARCH supplied defconfig
  savedefconfig   - Save current config as ./defconfig (minimal config)
  allnoconfig	  - New config where all options are answered with no
  allyesconfig	  - New config where all options are accepted with yes
  alldefconfig    - New config with all symbols set to default
  randconfig	  - New config with random answer to all options
  listnewconfig   - List new options
  olddefconfig	  - Same as silentoldconfig but sets new symbols to their default value

make[2]: Leaving directory '/home/sebo/zephyr/samples/bluetooth/beacon/outdir/nrf51_pca10028'
make[1]: Leaving directory '/home/sebo/zephyr'

To be specific. The answers to these questions should be obvious to most customers:

What is the difference between config and oldconfig?
What does "additionally update deps" mean?

An interface that looked something like this would be easier to understand I believe:

https://gist.github.com/SebastianBoe/23cca69b70a9a7f90000c50e37d1a888

[nashif]

most of those options are originally from Linux and not being used in Zephyr, we should only document those we use in Zephyr and those that are tested to work with how zephyr does configuration using kconfig.

[SebastianBoe]

I was not aware, yes, that should definitively be done.

Could you list here which options are supported by Zephyr? Maybe I could save some time
if I skip some targets while I am porting to CMake.

[nashif]

does not apply anymore