система плагинов на c++

может, если все "и так работает но.." достаточно ввести версионность ABI с гарантией, что оно будет только расширяться? тогда модуль А перед тем как использовать модуль Б проверит его версию и если она скажем меньше минимальной дает отлуп. дешево и сердито.

// wbr

может ввести какую нить штуку типа 

classA::method()
{
    if ( classB::is_have_method("name_of_method_from_class_B") )
    {
        //тоды делать 
    }  
}

полюбому можно красивее, и в эту сторону ... но башка ща не варит :(

сорри, если глупость сморозил

Не надо давать напрямую вызывать чужие функции. Нужно давать возможность обмениваться сообщениями; возможно, сделать оберточные "proxy objects" a-la CORBA.

Т.е. если у тебя есть APlugin, который умеет делать something, то интерфейс должен быть типа

if (pluginMessageQueue.send(APlugin::PLUGINID, APlugin::CALL_SOMETHING, somethingparams)) {

pluginMessageQueue.wait(APlugin::PLUGINID, APlugin::DONE__SOMETHING, &retval, timeout);

} else {

throw PluginException("\"A\" plugin required for this, please install it.");

}

который можно положить в метод CallSomething какого-нибудь AProxy.

Можно завести функцию, которая будет отвечать, поддерживается ли плугином указанная версия API. Например, если api версии 2 является расширением версии 1, то программе, поддерживающей api 1 надо ответить true. Если api версии 3 не является расширением версии 2, то при версии плагина 2 и версии программы 3 отвечать false.

А corba-у лучше не городить, т.к. она является попыткой приделать возможности скриптовых языков к компилируемым, что противоречит их сути.

PS. посмотри, как сделаны плагины в qt

Забить на объектную модель плюсов. Сделать все API extern C - но при этом вполне можно сохранить ОО. Тем самым люди смогут делать плагины не только на плюсах.

> А corba-у лучше не городить, т.к. она является попыткой приделать возможности скриптовых языков к компилируемым

Оооо какая феерическая чушь.

Всем спасибо за ответы.

Много думал. Решил, всеже, остановиться на сишном интерфейсе и сделать для этого интерфейса "обертку" в виде класса(ов).

Вариант с проверкой версии - слишком сердито. Обмен сообщениями - не нужное усложнение, как мне кажется (не думаю, что corba противоречит сути "компилируемых языков" =) )

Можно поинтересоваться зачем в "небольшой програмке для персонального использования" использовать плагины? И желать бинарной совместимости?

Плагины и бинарная совместимость нужны только если огромные толпы разработчиков будут независимо друг от друга писать разные фичи. В программе для персонального использования плагины и dlopen - это просто онанизм.

Автор топика, сосредоточься лучше на фичах, полезнее будет. Иначе вместо полезного функционала рискуешь реализовать никому не нужный загрузчик плагинов. Overengineering, вобщем, известная детская болезнь.

> Решил, всеже, остановиться на сишном интерфейсе и сделать для этого интерфейса "обертку" в виде класса(ов).

Ну _такого_ тебе вроде не предлагали :) как говорится, worst of both worldsю

Вполне намана, ничего криминального.

>Можно поинтересоваться зачем в "небольшой програмке для персонального использования" использовать плагины? И желать бинарной совместимости? Плагины и бинарная совместимость нужны только если огромные толпы разработчиков будут независимо друг от друга писать разные фичи. В программе для персонального использования плагины и dlopen - это просто онанизм. Автор топика, сосредоточься лучше на фичах, полезнее будет. Иначе вместо полезного функционала рискуешь реализовать никому не нужный загрузчик плагинов. Overengineering, вобщем, известная детская болезнь.

по опыту, возможно "детскому" опыту, мне проще реализовать "загрузчик плагинов" и отладить отдельно каждый из них.

Если действительно интересно, то я хочу написать программу, в которой интегрированы "домашняя бухгалтерия" + "список задач" + прочий мелкий pim. Хочу использовать сию программку как на десктопе, так и на nokia n800. Причем на десктопе хочу забубухать дополнительные плагины для построения красивых диаграмм по бухгалтерии. Хочу реализовать возможность синхронизации между n800<->десктоп.

ps вобщем планы, поменьшей мере, наполеоновские =)

> Вполне намана

А смысл? Написанный на Си++ плагин выставляет наружу Си-интерфейс, который потом оборачивается в Си++ использующей программой - это "намана"? Куда проще было бы сделать внешний интерфейс на Си++ "без вы*бонов", так что его при желании можно обернуть в Си для использования из какого-нибудь низкоуровневого языка ;)

> ничего криминального.

В УК нет такой статьи, это да :D

Делал в свое время объектную систему плагинов. Написал 3 бинарно совместимые реализации - на C++ (абстрактный класс), на C (структура) и на Delphi/Kylix (интерфейс). Еще мост для явы через JNI. Все красиво и круто как мне казалось - опрос доступных плагинов, вызовы одного плагина из другого и много чего еще.

Почитал Э. Реймонда - Искусство программирования для UNIX (рекомендую). Выкинул все к чертям собачьим. Сделал модули простыми исполняемыми программами, с запуском дочернего процесса и обменом текстовыми данными через stdin/stdout. Преимущества - никакой привязки к языку и реализации, легкое встраивание фильтра между любыми модулями (хоть скриптового), проблема в одном модуле не приводит к проблемам во всей системе - дочерний процесс легко убивается. А поверх этого можно и объектную систему построить если очень хочется.

> Написал 3 бинарно совместимые реализации - на C++ (абстрактный класс), на C (структура) и на Delphi/Kylix (интерфейс).

> ...

> Почитал Э. Реймонда - Искусство программирования для UNIX (рекомендую). Выкинул все к чертям собачьим. Сделал модули простыми исполняемыми программами, с запуском дочернего процесса и обменом текстовыми данными через stdin/stdout.

Хм, и остановился? Или планируешь прочитать еще какую-нибудь мудрую книгу и сделать 3-ю реализацию?

Всему свое место, время и средства. Я бы посмотрел, как ты сделаешь, например, VCS-плагин для IDE через "обмен текстовыми данными через stdin/stdout".

Не остановился конечно. Просто это основополагающая вещь, значительно изменившая мое представление о структуре программы.

Интерфейс должен быть отделен от реализации. Если нужно часть интерфейса сделать подключаемой, можно например описать его на XML и получать из модуля через те же stdin/stdout. Если ты имеешь в виду какую-то конкретную IDE, которая так не умеет - ну это проблема данной IDE (используйте emacs).

> Интерфейс должен быть отделен от реализации

Ну это настолько общее место, что даже и не возразишь.

> Если нужно часть интерфейса сделать подключаемой

"Часть интерфейса" - это что за штука?

> можно например описать его на XML и получать из модуля через те же stdin/stdout.

А можно на IDL, и подключать через CORBA. А можно через *.h-файл, и подключать через dlopen. А можно <вставьсюдалюбимыйспособ>

> Если ты имеешь в виду какую-то конкретную IDE

Нет, любую.

> (используйте emacs).

Посмотри на "плагины" emacs - какой из них является "внешним процессом, общающимся через stdin/stdout"? Я вот такого не припомню вообще - все работают внутри самого emacs. А знаешь, почему? Потому что stdin/stdout и Unix-вей в исполнении shell рулят тогда, когда у тебя простые структуры данных. Когда они становятся сложными, их начинают описывать на языках вроде IDL/Си/Lisp/whatever - иначе расходы на маршалинг взлетают до небес. Единственное преимущество твоей второй плагинной системы над первой - то, что падение плагина не влечет падения всего приложения.

Какие модули в emacs являются надстройками над внешними процессами? shell, term, emacs-w3m, pymacs, subversion, .......... на лиспе там только интерфейсные обертки. Для lisp-системы это самый простой способ прикрутить модуль, написанный на другом языке. Я как раз не знаю ни одного стороннего модуля, реализованного как so/dll.

> Какие модули в emacs являются надстройками над внешними процессами? shell, term, emacs-w3m, pymacs, subversion

Ты привел примеры, где emacs-плагин управляет работой _готовых_ внешних программ - там просто нет другого выхода, кроме управления через stdin/stdout. Там "плагином" является именно "интерфейсная обертка" (ха-ха, назвать какой-нибудь JDEE "оберткой" - это сильно 8))

> Я как раз не знаю ни одного стороннего модуля, реализованного как so/dll.

Зато ты знаешь КУЧУ модулей для emacs, реализованных на elisp, исполняющихся внутри emacs без всяких stdin/stdout и напрямую пользующихся предосталяемыми emacs'ом API. Теперь скажи, чем принципиально *.elc отличается от *.so? 8)

> Посмотри на "плагины" emacs - какой из них является "внешним процессом, общающимся через stdin/stdout"

XRefactory

правда там через сокет, данные скорее всего бинарные, и причины другие :)

>> Посмотри на "плагины" emacs - какой из них является "внешним процессом, общающимся через stdin/stdout"

> XRefactory

Это тоже управление готовой внешней прогой :) и наверняка куча нетривиального elisp, которая и является плагином

> правда там через сокет, данные скорее всего бинарные, и причины другие :)

ога :D

> Зато ты знаешь КУЧУ модулей для emacs, реализованных на elisp, исполняющихся внутри emacs без всяких stdin/stdout и напрямую пользующихся предосталяемыми emacs'ом API. Теперь скажи, чем принципиально *.elc отличается от *.so? 8)

Естественно, это же интерпретатор. Зачем там плагины, если можно просто исходник положить, который подхватится платформой? elc отличается от so тем, что это преобразованный для ускорения разбора исходник. В теме речь идет о C++ (позволь напомнить), где обеспечить модульность таким способом не получится.

> stdin/stdout и Unix-вей в исполнении shell рулят тогда, когда у тебя простые структуры данных. Когда они становятся сложными, их начинают описывать на языках вроде IDL/Си/Lisp/whatever - иначе расходы на маршалинг взлетают до небес.

Когда структуры становятся сложными, усложняется передаваемый контент. Вместо простого текста будет XML/JSON. Переход на DSO делается когда все это становится критичным по скорости, но на практике это не так уж часто. CORBA к стати тут ничем не поможет. Мое мнение - предлагать в качестве универсального решения CORBA-подобную модель и прочие реализации через DSO - неоправданное усложнение.

> Когда структуры становятся сложными, усложняется передаваемый контент.

Правда? :D

> Вместо простого текста будет XML/JSON.

> ...

> Мое мнение - предлагать в качестве универсального решения CORBA-подобную модель

А... так XML/JSON - это не CORBA-подобное? А я, по серости своей. думал, что это всё - разные ракурсы одних и тех же яиц под обобщенным названием "RPC" - там, где есть формальное описание передаваемых данных на каком-то языке.

Если ты хочешь реализовать "плагины", у которых на входе JSON/XML - пожалуйста, но это уже не классический Unix-way, это форма RPC. Кстати, а если плагину нужно порулить материнским приложением - как он это будет делать? Это приложение тоже будет читать со stdin? 8) Тоже будет реализовывать какой-то API через XML/JSON?

> и прочие реализации через DSO - неоправданное усложнение.

CORBA - это отнюдь не обязательно DSO. Даже чаще - не DSO.

> это всё - разные ракурсы одних и тех же яиц под обобщенным названием "RPC"

RPC, и что? Почему это должно быть аргументом в защиту DSO? Пока простота системы позволяет, я использую простые данные, когда система усложняется - добавляю элементы RPC. При этом не меняется способ взаимодействия модулей. А DSO - это сложность реализации, сложность использования других языков, легко ломающаяся совместимость - вот и все, что я хочу донести до автора темы.

> А смысл? Написанный на Си++ плагин выставляет наружу Си-интерфейс

Это важно! Таким образом можно делать плагины и на голом С.

> который потом оборачивается в Си++

А это бантики для личного удобства.

> Куда проще было бы сделать внешний интерфейс на Си++

Внешний интерфейс с манглингом? Бюэ.

>А DSO - это сложность реализации, сложность использования других языков, легко ломающаяся совместимость - вот и все, что я хочу донести до автора темы.

в отсутствии реализации сложно говорить о "сложности реализации".

"сложность использования других языков" - насколько я знаю, вызов функции, имя которой известно, из библиотеки достаточно распростаненная вещь (я смотрел python, perl вроде тоже может, да и к bash'у можно прикрутить =) ).

"легко ломающаяся совместимость" - без конкретной реализации об этом так же говорить сложно.

> "сложность использования других языков" - насколько я знаю, вызов функции, имя которой известно, из библиотеки достаточно распростаненная вещь (я смотрел python, perl вроде тоже может, да и к bash'у можно прикрутить =) ).

А наоборот? Программа на C++ а модуль на perl?

> "легко ломающаяся совместимость" - без конкретной реализации об этом так же говорить сложно.

Да хотя бы разные версии gcc с периодически меняющимся ABI. И библиотеки разных версий гораздо проще подружить в разных процессах.

>> это всё - разные ракурсы одних и тех же яиц под обобщенным названием "RPC"

> RPC, и что? ... Пока простота системы позволяет, я использую простые данные, когда система усложняется - добавляю элементы RPC

Мне трудно представить программу, которая уже требует плагинной архитектуры, но всё еще оперирует простыми структурами данных.

> Почему это должно быть аргументом в защиту DSO?

Где именно я защищал DSO? И кстати, повторю вопрос - чем принципиально отличается *.elc от *.so?

>> Куда проще было бы сделать внешний интерфейс на Си++

> Внешний интерфейс с манглингом? Бюэ.

Еще раз, медленно и печально: плагин написан на Си++; программа, для которой он предназначен, тоже написана на Си++. И что - они должны общаться через интерфейс на Си? "Бюэ".

А в (маловероятном) случае, если этот плагин понадобится в другой проге, написанной не на Си++, можно написать интерфейс на Си. Или (за счет Си++ "без вы*бонов") сгенерировать его SWIG'ом - этот вариант лучше еще и тем, что он сразу объектно-ориентированный, в отличие от варианта с Си.

> Я бы посмотрел, как ты сделаешь, например, VCS-плагин для IDE через "обмен текстовыми данными через stdin/stdout".

Разве clearcase-плагин для eclipse не тупо вызывает соответствующие тулы? Хотя формально да, он с ними через stdin/stdout не общается :)

> плагин написан на Си++; программа, для которой он предназначен, тоже написана на Си++

Если на этом жизнь кончается - Вы на 101% правы. Если программа будет развиваться и расти дальше - прав я. Особенно если однажды встанет вопрос двоичной совместимости. Помню, как после каждого апгрейда мозиллы (с плюсовым ABI) надо было пересобирать галеон (сишный). Жуть.

> Где именно я защищал DSO?

Ты утверждал, что я с помошью дочернего процесса не реализую VCS-плагин для IDE. Так какие твои предложения?

> чем принципиально отличается *.elc от *.so

Платформой. Интерпретатор избавляет от необходимости городить плагины, потому что структура приложения может меняться динамически.

> Где именно я защищал DSO?

Ты утверждал, что я с помошью дочернего процесса не реализую VCS-плагин для IDE. Так какие твои предложения?

> чем принципиально отличается *.elc от *.so

Платформой. Интерпретатор избавляет от необходимости городить плагины, потому что структура приложения может меняться динамически.

>А наоборот? Программа на C++ а модуль на perl?

не знаю как насчет perl'а, а для пайтона придется сделать одну небольшую оболочку, единую для всех пайтоновских плагинов: http://docs.python.org/ext/callingPython.html

Предлагаешь путь mod_python, mod_perl, mod_php, ...? Вариант конечно, но реально apache собирают с поддержкой только того, что нужно, а cgi позволяет не привязываться заранее к технологии реализации плагина.

> Ты утверждал, что я с помошью дочернего процесса не реализую VCS-плагин для IDE

Небольшая поправка - ни для одной из существующих IDE.

> Так какие твои предложения?

Код, работающий _внутри_ IDE.

>> чем принципиально отличается *.elc от *.so

>Платформой.

...то есть ничем. Мы же не станем говорить, что набор команд (машкод против кода виртуальной машины) - это качественное отличие? 8)

> Интерпретатор избавляет от необходимости городить плагины

Программа на интерпретируемом языке состоит из плагинов, которые общаются отнюдь не через stdin/stdout 8)

gaa (*) (05.12.2007 16:07:44)

>> Я бы посмотрел, как ты сделаешь, например, VCS-плагин для IDE через "обмен текстовыми данными через stdin/stdout".

>Разве clearcase-плагин для eclipse не тупо вызывает соответствующие тулы?

Плагин - вызывает, да. И что - от этого сами CLI-тулы становятся плагином? Плагин еще много чего делает, и для этого ему абсолютно необходим доступ к API Eclipse'а.

>> плагин написан на Си++; программа, для которой он предназначен, тоже написана на Си++

>Если на этом жизнь кончается - Вы на 101% правы. Если программа будет развиваться и расти дальше - прав я.

Такое впечатление, что Вы не прочитали то, что было написано дальше :/

> Помню, как после каждого апгрейда мозиллы (с плюсовым ABI) надо было пересобирать галеон (сишный)

И? AFAIK, у Мозиллы просто _нет_ внешнего интерфейса для Си-приложений. Вот если бы надо было пересобирать прогу на Си++,,, это значит, что gcc хреново реализовал Си++ ABI :)

>> Разве clearcase-плагин для eclipse не тупо вызывает соответствующие тулы?

> Плагин - вызывает, да. И что - от этого сами CLI-тулы становятся плагином? Плагин еще много чего делает, и для этого ему абсолютно необходим доступ к API Eclipse'а.

Что делает плагин для clearcase принципиально отличного от плагина для cvs или subversion? Ничего.

Соответственно, можно выделить отдельный тип плагина "rcs plugin" а уж его как угодно вызывать(хоть через stdin/sdtout, а то и вовсе через параметры запуска), ведь возможных операций там раз-два-и-обчёлся: ci/co/unco/diff/tree.

> Соответственно, можно выделить отдельный тип плагина "rcs plugin" а уж его как угодно вызывать

Отлично. Где будет жить (исполняться) этот вызывающий код и что он будет делать? Подсказка: он будет жить внутри Эклипсы, и будет вызывать как CLI-тулы, так и внутренние API Эклипсы. И именно в _этом_ разница - в доступе к богатым внутренним API материнского приложения, которые _никто_ (AFAIK) не выставляет через stdin/stdout/XML/JSON - потому что они слишком сложны.

> возможных операций там раз-два-и-обчёлся: ci/co/unco/diff/tree.

Ты вообще хоть о чем-нибудь, кроме CVS, знаешь? 8) SVN не в счет, это тоже такая CVS.

>> Соответственно, можно выделить отдельный тип плагина "rcs plugin" а уж его как угодно вызывать

> Отлично. Где будет жить (исполняться) этот вызывающий код и что он будет делать? Подсказка: он будет жить внутри Эклипсы, и будет вызывать как CLI-тулы, так и внутренние API Эклипсы.

Да. Это будет поддержка rcs плагинов со строны IDE.

>> возможных операций там раз-два-и-обчёлся: ci/co/unco/diff/tree.

> Ты вообще хоть о чем-нибудь, кроме CVS, знаешь? 8) SVN не в счет, это тоже такая CVS.

Ну и что же я упустил? Деливерим всё равно через clearcase project explorer, а в менюшку внутри eclipse встроены только описанные мной команды. Ах, да, есть ещё отображение статуса файла(checkedout/hijacked...).

>> Отлично. Где будет жить (исполняться) этот вызывающий код и что он будет делать? Подсказка: он будет жить внутри Эклипсы, и будет вызывать как CLI-тулы, так и внутренние API Эклипсы.

> Да. Это будет поддержка rcs плагинов со строны IDE.

Уфф. Слушай, объясни мне по-человечески - что ты называешь rcs-плагином? Подробно, для тупых. И чем "поддержка rcs плагинов со строны IDE" не плагин.

>> Ты вообще хоть о чем-нибудь, кроме CVS, знаешь? 8) SVN не в счет, это тоже такая CVS.

>Ну и что же я упустил?

Да мелочевку всякую... ну там push/pull (есть во всех современных DVCS), вещи типа hg in/hg out (такое есть и в git/bzr/mtn), hg qpush/qpop (есть и для git в виде stg). Это еще не говоря об экзотике вроде работы с атрибутами в Monotone и управления ключами там же. В общем, свести всё к CVS можно, только кому такой плагин нужен?

> Слушай, объясни мне по-человечески - что ты называешь rcs-плагином? Подробно, для тупых. И чем "поддержка rcs плагинов со строны IDE" не плагин.

rcs-плагин - вещь, которая выполняет какие-то предопределённые операции для работы с данной rcs. Их поддержка в IDE - менюшки/обработки действий при которых надо выполнить что-то с rcs.

И та часть, которая со стороны IDE не должна знать о том, какой именно rcs-плагин используется. Она просто даёт ему команду checkout. А уж плагин вызывает cleartool co или subversion co. И так же можно добавить новые плагины.

> Да мелочевку всякую... ну там push/pull (есть во всех современных DVCS), вещи типа hg in/hg out (такое есть и в git/bzr/mtn), hg qpush/qpop (есть и для git в виде stg). Это еще не говоря об экзотике вроде работы с атрибутами в Monotone и управления ключами там же. В общем, свести всё к CVS можно, только кому такой плагин нужен?

Понятно что, меня загрузили кучей непонятных слов :)

Есть два вопроса:

1. Действительно, зачем в программе для домашнего использования плагины? ОК, если очень хочется то можно, но - уж бинарную-то совместимость плагинов можно гарантировать, не так ли?

2. Как спасет Сишный интерфейс, если изменится не название функции, а ее сигнатура? dlsym тут ничем не поможет. Какие преимущества у Си перед С++? (Единственное преимущество - то, что so-шки с С-шными интерфейсами могут быть собраны любыми компиляторами; для С++ лучше использовать все же один и тот же компилятор - но опять же, разве это проблема в случае программы для домашнего использования?)

> Такое впечатление, что Вы не прочитали то, что было написано дальше :/

Прочел. И про swig тоже. Но swig не гарантирует Вас от таких вещей, как разный манглинг у разных компиляторов(версий).

> у Мозиллы просто _нет_ внешнего интерфейса для Си-приложений

Именно. На это и ругаюсь. Все-таки в унихе (не в беос) API/ABI должен быть сишным, если по-хорошему. Конечно, для самоделок без разницы...

>> Слушай, объясни мне по-человечески - что ты называешь rcs-плагином? Подробно, для тупых. И чем "поддержка rcs плагинов со строны IDE" не плагин.

> rcs-плагин - вещь, которая выполняет какие-то предопределённые операции для работы с данной rcs

Этот уровень абстракции для меня слишком высок. Давай конкретно (на примере Eclipse): что такое этот "rcs-плагин" - скрипт/бинарь/.so/.jar/Eclipse plugin? Необходима ли ему для выполнения Eclipse? Или хватит shell prompt голой ОС?

> поддержка в IDE - менюшки/обработки действий при которых надо выполнить что-то с rcs.

Хотелось бы всё-таки узнать: вот эта "поддержка в IDE" - это плагин или нет?

> по опыту, возможно "детскому" опыту, мне проще реализовать "загрузчик плагинов" и отладить отдельно каждый из них.

Отладка, конечно весьма индивидуальный процесс, и тут хозяин-барин. мои доводы против плагинов были в том что

- Плагиновая архитектура требует писать загрузчик плагинов, вместо того чтобы просто все слинковать.

- Плагиновая архитектура требует зафиксировать интерфейс между частями. Это либо невозможно на раннем этапе, либо требует дополнительных усилий

+ Плагиновая архитектура дает возможность грузить части программы динамически. Лично мне совершенно неясно как это может помочь в отладке и в персональном проекте вообще.

Таким образом имеем два практических минуса, и один теоретический плюс .

> Если действительно интересно, то я хочу написать программу, в которой интегрированы "домашняя бухгалтерия" + "список задач" + прочий мелкий pim. Хочу использовать сию программку как на десктопе, так и на nokia n800. Причем на десктопе хочу забубухать дополнительные плагины для построения красивых диаграмм по бухгалтерии. Хочу реализовать возможность синхронизации между n800<->десктоп.

Все равно неясно, зачем плагины. Скорее всего надо будет тянуть только две сборки - со всеми диаграмами или без. Почему нельзя сделать #ifdef WITH_CHARTS_BUILDER ... #endif ? Который потом, когда (и если) проект наберет популярность, можно будет заменить на плагины.

AFAIK большинство проектов (Linux, Apache, etc) двигалось именно так - сначала core functionality в виде монолита, а уже потом динамический загрузчик драйверов/плагинов/фич.

А зачем вообще писать это на плюсах?

Или цель именно потрахаться? (с)

> swig не гарантирует Вас от таких вещей, как разный манглинг у разных компиляторов(версий).

SWIG вообще ничего не гарантирует 8), но всё же сильно облегчает жизнь, если не хотеть странного. А манглинг, если моя память мне ни с кем не изменяет, входит в стандарт ABI, который довольно давно поддерживается gcc.

>>> Слушай, объясни мне по-человечески - что ты называешь rcs-плагином? Подробно, для тупых. И чем "поддержка rcs плагинов со строны IDE" не плагин.

>> rcs-плагин - вещь, которая выполняет какие-то предопределённые операции для работы с данной rcs

> Этот уровень абстракции для меня слишком высок. Давай конкретно (на примере Eclipse): что такое этот "rcs-плагин" - скрипт/бинарь/.so/.jar/Eclipse plugin? Необходима ли ему для выполнения Eclipse? Или хватит shell prompt голой ОС?

В эклипве сейчас плагин - это набор jar-ов, которые из себя и представляют плагин. Они работают внутри эклипса и от других плагинов вроде принципиально не отличаются от других типов плагинов.

>> поддержка в IDE - менюшки/обработки действий при которых надо выполнить что-то с rcs.

> Хотелось бы всё-таки узнать: вот эта "поддержка в IDE" - это плагин или нет?

Нет. (напоминаю, что я описываю то, что в том же эклипсе сейчас отсутствует) Поддержка в IDE - это вещь, которая общается с плагинами. В принципе, плагином может оказаться и просто список соответствия операции и выполняемого действия. Например для shell и clearcase(при этом формат вызова плагина: plugin <action> <file>):

#!/bin/sh

case $1 in
checkout)
ct co "$2"
;;
checkin)
ct ci "$2"
;;
uncheckout)
ct unco "$2"
;;
esac