LINUX.ORG.RU
Форум — Development  

Как поддерживать для разных клиентов немного разные версии одной программы?


0

0

Есть программа ( даже не программа, а комплекс состоящий из исходников, документации, тестов, примеров ну и т. д. )

Программа специфическая.
Для каждого клиента она немного разная. Для одного предположим десяток переменных, для другого есть ещё одиннадцатая и соответсвенно маленький кусочек, вставляемый в функцию специально для обработки одиннадцатой переменной. Для одного есть данный кусок файла Readme, для другого нет ну и т. д. Пока таких различий было мало и было мало клиентов, приемлемо было использование условной компиляции, но с возросшим числом клиентов и постепенным совершенствованием программы число #ifов возросло просто до неприличия и программа утратила читабельность и стало сложно её отлаживать.
К тому же не всегда можно "обновлять" программу у клиента. Т. е. нормальной является ситуация когда у одного клиента в программе остался баг (и не исправляется специально), у другого данный баг исправлен и добавлен десяток новых свойств. Но в общих чертах программа одна и развивается как единое целое. Поддерживать надо обоих. Специфика области.

Дерево держит CVS.

Вопрос: какие есть альтернативы условной компиляции для такой ситуации? Какие (желательно проверенные временем) варианты можно использовать?
Как в рамках одного дерева исходников поддерживать несколько версий программы одновременно? Причём с минимальной разницей в одну строку кода?

★
← Генератор отчетов
Линукс и реальное время или почему fflush не работает как надо → 

> Для одного предположим десяток переменных, для другого есть ...
Конфигурационные файлы

> Как в рамках одного дерева исходников поддерживать несколько версий
Чекпоинт

aton ★
()

Вопрос реально интересный. А через define -ы разрулить не получилось ?

anonymous
()
Ответ на: комментарий от aton

конфигурационные файлы не подходят.
К программе предъявляются требования Real-Time систем, поэтому паразитные ifы внутри скомпилированной программы неприемлемы.

Сейчас всё на #define ...
#ifdef ...
и держится. Но так как куча мелких исправлений и дополнений, то текст просто нечитабелен и сложен в отладке.

Самая большая проблема в том, что нет генеральной линии развития программы. Т. е. версия, находящаяся у конкретного клиента и есть для него последняя версия. И все исправления (недостатки, усовершенствования ) вносимые в его версию далеко не все и совсем не сразу добавляются остальным клиентам. Т. е. у каждого получается как бы немного своя программа. Т. е. нет модели ядро (которое обновляется у всех)и плагины/настройки(доп. функциональность), а есть некий аморфный набор кода, собираемый для каждого клиента и потихоньку "эволюционирующий" с оглядкой на других клиентов.

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

ksicom ★
() автор топика
Ответ на: комментарий от ksicom

> В общем нужно что-нибудь, что умеет по условно имени клиента собрать из кусков/базы данных, ещё чего-нибудь для конкретного клиента прозрачный и нормально читабельный код. И так же умеющее добавлять куски как в общий так и в персональный код.

Логичнее всего использование branch в svn для каждого клиента. С последующим merge нового кода в main.. Но всеравно будет громоздко и страшно.. Точнее - ветки-то будут на ура делатся.. А вот обратно их собирать в main будет проблема.

IMO: Вам нужна не программа а пересмотр политики разработки. Потому что с текущей у вас будет получатся разрастающееся дерево, с поддержкой которого будет возникать всё больше и больше проблем.

nblx
()
Ответ на: комментарий от nblx

Пересмотреть политику разработки ещё сложнее )))

Слышал где-то по данной тематике термин "фасеточное программирование", но чего-то найти ничего не могу :(

ksicom ★
() автор топика
Ответ на: комментарий от ksicom

Поддерживаю замечание по поводу политики

Уж лучше волевым усилием изменить политику разработки. А то дальше будет только хуже.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Генератор отчетов
Development
Линукс и реальное время или почему fflush не работает как надо →