I'm working on an open-source embedded project which requires quite a lot of configuration - distortos - object-oriented C++ RTOS for microcontrollers. When starting a new project you can select the chip you will be targeting from several hundred supported devices, after that you may select the configuration of chip's clock (PLL multipliers, dividers, quartz crystal frequency, ...) and chip's peripherals (whether to enable serial port 1, serial port 2, serial port 5 and so on). During project's evolution you can configure other features of the RTOS (like sizes of stacks, run-time checking and so on).
At this moment the project uses kconfig-frontends, which is a tool used to configure Linux kernel - extracted to be a separate, standalone project. My configuration menus currently look more or less like this:
While kconfig-frontends has quite a lot of nice features, it also has some very serious flaws.
- Impossible to build on Windows - one guy created a Windows build of a pretty old 3.12.0 version some time ago, but I never managed to reproduce his results, and his compilation covers only the "mconf" variant (ncurses-bases - pictured above), all other tools are not present in the binary package he uploaded.
- Unknown whether it builds on Mac.
- In most Linux distros you have to manually build it yourself from source. This is a problem, as people working with microcontrollers (users of my project) are not very used to doing that, and the process is not that easy as you would imagine.
- Doing some things is extremely tedious - for example you can "force select" an option, but you cannot "force unselect" it, except hiding it from the user...
- Doing some things is impossible - for example dependencies can only be based on bool values, you cannot have some options depend on an exact integer value or a string.
- (related to 5.) There are limited possibilities for checking the validity of user's input - for example for integers you can only allow a contiguous range of values, while sometimes a list of valid integers would be more suitable (this can be worked around with a list of bools + hidden integer with default value based on bool, but then see 4. - this is not very practical if there is more than - say - a dozen of allowed values).
- I probably forgot about something anyway...
Mainly because of first three items I'm considering moving to some other tool. But the problem here is that I actually only know one alternative - cmake-gui (or ccmake). It nicely solves the most important problems listed above (1-3), but doesn't solve all of them - I'm pretty sure points 4-6 remain in place, maybe affecting some different areas, but still... There are also some more issues with cmake:
- With kconfig-frontends the hierarchical structure of the configuration can be freely created - you can have as many levels of menus as you like, arranged anyway you want. With cmake the configuration is flat, with the possibility to group the options by the prefix of each value (more-or-less something like a menu with 2 levels in kconfig-frontends).
- There are only strings and bools as "types" of options, having integers with value checking requires some workarounds.
- The dependencies among options is very cumbersome. In kconfig-frontends if "option B" depends on "option A" being enabled, then changing value of "option A" results in "option B" being immediately hidden or displayed to the user. In cmake-gui when you have such dependencies, you have to click "Configure" to actually see any effect.
My question therefore is - are there any other alternatives to kconfig-frontends and cmake-gui? The most important features I'm after are:
- easy to use on all major OS platforms;
For other features I'm flexible and I may adapt.
I also know that I could write my own configuration tool and ship that with the project, but I'd really prefer not to go that way, unless forced by lack of other options. I prefer to have some GUI tool instead of a typical approach of embedded project - requiring the user to manually edit some header files with all the options. This is because there are way too many things to configure (even though I try to keep the number of options down to a minimum), most of options depending on some other options, and also because some of the options affect the build process, so using .h file for that is not very convenient.