Обычный способ состоит в том, чтобы выставить некоторые команды CLI и позволить пользователям использовать их на любом языке оболочки / скрипта, который пишет пользователь; см. например imagemagick, который предоставляет ряд команд для преобразования изображений между форматами и применения преобразований. Это хорошо работает в любой ОС.
Это также может работать с интерактивными программами, хотя это редко. Вы можете использовать интерфейс D-BUS (который становится все более популярным как в GNOME, так и в KDE), хотя он больше подходит для обработки событий или отправки простых команд. Возможно, вы захотите создать интерактивную или демоноподобную программу, которая предоставляет интерфейс D-BUS (или даже простой на основе сокетов / каналов), а также некоторые простые вызовы CLI, которые обертывают отправку команд, что упрощает интерфейс. См. moc / mocp («Музыка на консольном проигрывателе») или xmms2. Это хорошо работает в любой ОС, но обычно требуется некоторое время, чтобы проработать детали реализации на разных ОС.
Не бойтесь встраивать полный язык. Такие языки, как Lua или Guile, были разработаны так, чтобы их было очень просто внедрить и они были достаточно мощными. Стандартизация одного из таких языков не всегда плохая вещь, так как это означает большее повторное использование кода между пользователями ... и язык на самом деле имеет значение, только если вы планируете, чтобы пользователи писали большие куски кода в виде плагинов.
Есть несколько способов представить API для нескольких языков сценариев с помощью специальных библиотек. Вы можете прочитать о них, например. здесь: Kross @ Wikipedia . У меня нет с ними опыта.
Я предполагаю, что ваша программа будет с закрытым исходным кодом ... Тогда последний вариант, который я вижу, - это показать какой-то интерфейс API / ABI, который может использоваться программами пользователя C (например, скомпилированными в динамическую библиотеку). Таким образом, пользователи смогут создавать обертки для любого языка, который они хотят, плюс они могут создавать код на простом С для скорости. Это решение может быть трудно сделать переносимым, но оно дает вам (и вашим пользователям) гибкость.
Обратите внимание, что легко переписать возможности написания сценариев: лучше оставлять конструкции программирования на внешних языках и предоставлять только простые средства взаимодействия с вашей программой. Я видел программы, которые добавляли свои собственные возможности зацикливания к языкам сценариев, даже если они не добавляли никакой пользы для пользователя: f.e. возможность передавать несколько изображений за один раз, даже если это не ускоряет обработку.