Редактор конфигурации проекта – альтернатива kconfig-frontends и cmake-gui

Я работаю над проектом с открытым исходным кодом для встроенных систем, который требует довольно много настроек – distortos – объектно-ориентированная C++ RTOS для микроконтроллеров. При создании нового проекта вы можете выбрать микросхему из нескольких сотен поддерживаемых устройств, затем можно выбрать конфигурацию тактового генератора микросхемы (множители PLL, делители, частота кварцевого кристалла и т.д.) и периферии микросхемы (включать ли последовательный порт 1, последовательный порт 2, последовательный порт 5 и так далее). В процессе эволюции проекта вы можете настроить другие функции RTOS (например, размеры стеков, проверку во время выполнения и так далее).

На данный момент проект использует kconfig-frontends, который является инструментом для настройки ядра Linux – выделенным в отдельный независимый проект. Мои меню конфигурации в настоящее время выглядят примерно так:

Хотя kconfig-frontends имеет довольно много хороших функций, у него также есть некоторые серьезные недостатки.

1. Невозможно собрать на Windows – один человек создал сборку для Windows довольно старой версии 3.12.0 некоторое время назад, но мне так и не удалось воспроизвести его результаты, и его компиляция охватывает только вариант “mconf” (на основе ncurses – показан выше), все остальные инструменты отсутствуют в бинарном пакете, который он загрузил.
2. Неизвестно, собирается ли на Mac.
3. На большинстве дистрибутивов Linux вы должны вручную собирать его из исходников. Это проблема, поскольку люди, работающие с микроконтроллерами (пользователи моего проекта), не очень привыкли к этому, и процесс не так прост, как можно было бы представить.
4. Некоторые действия чрезвычайно утомительны – например, вы можете “принудительно выбрать” опцию, но не можете “принудительно отменить выбор”, кроме как скрыв ее от пользователя…
5. Некоторые вещи сделать невозможно – например, зависимости могут быть основаны только на логических значениях, вы не можете сделать так, чтобы некоторые опции зависели от точного целого значения или строки.
6. (связанный с 5.) Возможности проверки действительности ввода пользователя ограничены – например, для целых чисел вы можете разрешить только непрерывный диапазон значений, в то время как иногда список допустимых целых чисел был бы более уместен (это можно обойти с помощью списка логических значений + скрытого целого значения с значением по умолчанию, основанным на логическом, но затем см. пункт 4 – это не очень практично, если допустимых значений больше – скажем – дюжина).
7. Я, вероятно, что-то забыл в любом случае…

В основном из-за первых трех пунктов я рассматриваю возможность перехода на другой инструмент. Но проблема в том, что на самом деле я знаю только одну альтернативу – cmake-gui (или ccmake). Он хорошо решает большинство перечисленных выше проблем (1-3), но не решает все из них – я уверен, что пункты 4-6 остаются на месте, возможно, затрагивая некоторые другие области, но все же… Также есть некоторые другие проблемы с cmake:

1. С kconfig-frontends иерархическая структура конфигурации может быть свободно создана – вы можете иметь столько уровней меню, сколько захотите, расположенные как угодно. С cmake конфигурация плоская, с возможностью группировки опций по префиксу каждого значения (более-менее что-то вроде меню с 2 уровнями в kconfig-frontends).
2. Существуют только строки и логические значения как “типы” опций, для целых чисел с проверкой значений требуется некоторые обходные пути.
3. Зависимости между опциями очень громоздки. В kconfig-frontends, если “опция B” зависит от включения “опции A”, то изменение значения “опции A” приводит к тому, что “опция B” мгновенно скрывается или отображается пользователю. В cmake-gui, когда у вас есть такие зависимости, вы должны нажать “Configure”, чтобы увидеть эффект.

Один из пользователей моего проекта создал предварительный порт на cmake, и он выглядит так:

Таким образом, мой вопрос – существуют ли какие-либо другие альтернативы kconfig-frontends и cmake-gui? Самые важные функции, которые мне нужны, это:

• легкость использования на всех основных платформах ОС;
• GUI;

Я готов быть гибким в отношении других функций и могу адаптироваться.

Я также знаю, что мог бы написать свой собственный инструмент конфигурации и поставлять его с проектом, но я действительно предпочел бы не идти по этому пути, если только не буду вынужден отсутствием других вариантов. Я предпочитаю иметь какой-то инструмент с графическим интерфейсом, вместо типичного подхода к встраиваемым проектам, требующего от пользователя вручную редактировать некоторые заголовочные файлы со всеми опциями. Это потому, что есть слишком много вещей для настройки (несмотря на то что я стараюсь уменьшить количество опций до минимума), большинство опций зависят от других, а также потому, что некоторые из опций влияют на процесс сборки, поэтому использование .h файла для этого не очень удобно.

Я тоже изучаю эту проблему (нужен портативный инструмент для обработки опций конфигурации с пользовательским интерфейсом), и нашел проект Kconfiglib. Это реализация kconfig, написанная на Python, поддерживает консольный и графический интерфейсы. Пожалуйста, смотрите: https://github.com/ulfalizer/Kconfiglib

(Я на начальной стадии и еще не проверял инструмент. Возможно, Kconfiglib будет полезен кому-то другому.)