nasa
gui/menu/wizard configuration
Is your feature request related to a problem? Please describe. For noobs, it can be daunting to configure a cFS environment, or to find "that one parameter that changes the size of the pipe tables", for example.
Describe the solution you'd like It would be nice to have a configuration ...generator...? that a user could use to quickly run through the configuration options (conditional code options, platform selection, sizing options) and generates the appropriate CMake files, .h files, startup scripts, etc.
Describe alternatives you've considered menuconfig/kconfig (https://en.wikipedia.org/wiki/Menuconfig) is a popular option and provides a menu-based configuration system. Alternatively, a "wizard" style configuration (like Perl's Configure script) that steps through all of the configuration options, asking questions and providing default answers.
Whatever option is chosen, it should not replace the existing build process but should be a front-end to it, and provide human-readable/editable files as output that are equivalent to the current files.
Requester Info [email protected]
There is also a CMake GUI tool that can be used to configure this stuff. I haven't tried it, but I think it relies on these being a "cache" variables or declared as an option(), and presents them in a gui with a description and allows one to configure them. Might be worth looking into, the CMake files might need some adjustment to make it work but it shouldn't be too bad.
I took a cursory look at both CMake GUI and menuconfig/kconfig.
CMake GUI was just a quick install and it picked up on some settings automatically but it only has bool, path, filepath, and string types and no option dependencies or multi-selections like Kconfig.
Menuconfig/Kconfig on the other hand required that I install linux kernel source for my desktop and a few other items before I could call 'make menuconfig' for the kernel and get a menu on screen. Once that was operational I was able to call '/usr/src/linux-source-5.4.0/linux-source-5.4.0/scripts/kconfig/mconf mykconfig' and experiment with the language. I then added the path for mconf to my $PATH for easier use.
This setup would allow one to call e.g. 'mconf cfsKconfig' and it generate a .config file completely separately from the existing make system.
To allow for one to call 'make menuconfig' in a self contained fashion there are a number of other files that would have to be included in the project - so users don't have to go through the kernel source install process. Luckily there is https://github.com/masahir0y/kbuild_skeleton which is a self-contained example of an other-than-linux-kernel project that utilizes 'make menuconfig' to bring up the Kconfig menu.
Where should I look for the list of cFS make vars, their types, and possible/allowable values so I can write a Kconfig file for them?
@Emil-DV Ooh I like the CMake GUI and is more targeted to the build env we use.
It is looking like @jphickey and others are migrating a lot of configuration options from header files to CMake files, so this will increase the value of this.
(Most) everything that a "user" of cFS would want to configure would be in the "defs" folder, be it *_mission_cfg.h, *_platform_cfg.h, but mostly *.cmake.
I'll try playing with the CMake GUI in the next week or so; perhaps we can update the "build and run" section of the README.md to give the step-by-step of running the GUI.
osconfic.cmake is an important one, and a few tickets have mentioned converting the cfe configuration to cmake (nasa/cFE#796 for example). If this tool makes the management of those files easier this could definitely help out with configuration/deployment!
The one thing that I don't like about CMake GUI is the lack of a multi-selection string type. e.g. BUILD_TYPE = (one of) Debug | Relese | MinSizeRel | RelWithDebInfo. Although those options could be put in the description field, the search feature does not include that field.
menuconfig/kconfig has the ability to present a multi-selection but no dialog for selection of file or filepaths, it has cryptic error messages that make it difficult to debug, and the language is poorly documented. Clearly it was not designed to be a general purpose tool.
The 'dialog' package looks like an interesting way to add GUI items to a configuration script and it has both multi-selection and file/filepath browse functions. An alternate to cmake-gui could be built using dialog that read/writes the same CMakeCache.txt file yet has the addition of multi-selections and a search function.