OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Понедельник, 25 Июнь, 2018 04:53

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 21 ]  На страницу 1, 2  След.
Автор Сообщение
СообщениеДобавлено: Четверг, 03 Март, 2011 22:26 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2504
Откуда: Россия, Ярославль
В процессе развития довольно сложных приложений и используемых ими компонент возник концептуальный, на мой взгляд, вопрос.

Допустим, в совместной разработке находятся подсистемы А, Б, В. Средство контроля версий используется регулярно. В целом, можно считать, что исходный код (Mod) и ресурсы (Rsrc) синхронизированы, документацию не рассматриваю. Кодовые (Code) и символьные (Sym) файлы исключены из-под контроля версий по соображениям рациональности.

В периоды автономной работы, у каждого из разработчиков накапливаются изменения. Для простоты, примем, что каждый разработчик "ведёт" свой компонент, и чужие не трогает, то есть, изменения собственно исходного кода не пересекаются (пересечение, кстати, отдельный момент, есть мысль про diff-плагин для HG).

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

А так как фреймворк следит за соответствием и не даёт вызвать модули, которые скомпилированы для другой версии (т.н. inconsistent import). Имеет проблему рассинхронизации кодовых файлов а не исходного кода.

Коллизия может возникнуть, например, если я развиваю свою подсистему А локально, вношу изменения, приводящие к ii, после этого, я кладу изменения в репозиторий.

Коллега, видит по логу репа, что есть изменения в библиотеке А, компилирует её сразу, но, при этом не компилирует подсистему Б, которая от неё зависит, при этом, в достаточно сложной системе может просто отсутствовать возможность быстро проверить работоспособность всех функций. В итоге, в какой-то момент времени, возникает коллизия.

Затем, ещё кто-то, компилирует подсистему С, от которой зависит А, в свою очередь, коллега опять компилирует подсистему С, при этом, цепочка А-Б оказывается неработоспособной из-за ii.

Покрутив в голове, мы пришли к двум возможным решениям:
  • либо, не рассматривать кодовые файлы как нечто постоянное и отважно удалять их, перекомпилируя ВСЮ систему в целом. Что может быть невозможным, при отсутствии исходников, либо, при наличии постоянно развивающихся исходников, либо, окажется неадекватным, вследствие необходимости передать малый пакет изменений системы О на рабочие места.
  • либо создать систему, которая при компиляции составляла что-либо вроде снимка системы О, журналируя состояние версий модулей и исходников, и которая минимум сигнализировала бы о найденном несоответствии.

Конечно, у нас есть способ сравнивать кодовые файлы только по коду, и выделять изменённый код, игнорируя метки даты. Тем самым, вариант номер раз вполне реально использовать в ряде случаев. Но он мне кажется скорее хаком, нежели тем, на что можно опереться системно, потому что, если я уже успел наваять ещё изменений в А, то автоматика споткнётся уже на моей стороне.

В связи с этим хотелось бы осмыслить проблему вообще. Сформулировать, и всё такое.

Ну и, насчёт хранения кодосимвольных в репе - это не выход, это просто транслирование моей версии всем, но они и так её получат, скомпилировав тут же, по выходу из системы контроля версий


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Март, 2011 22:46 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 2846
Откуда: Астрахань
Нужен мейкер в ББ?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Март, 2011 23:10 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2504
Откуда: Россия, Ярославль
Пожалуйста, точнее опишите своё предложение.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Март, 2011 08:15 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 2846
Откуда: Астрахань
Не верю, что вы не пользовались мейкером!
В *любой интегрированной среде для С++ такая прога есть обязательно!
А в прежние времена с ней работали из командной строки.

Но все же напишу.
Мейкер - это программа, которая отслеживает временнЫе зависимости файлов-модулей проекта.
Для нее на простом языке пишется файл (текстовый), где прописываются зависимости файлов друг от друга.
Мейкер на основе этой информации запускает трансляцию соответствующих модулей и сборку нового исполняемого модуля.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Март, 2011 09:16 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4485
Откуда: Россия, Орёл
Чем возиться с прописыванием зависимостей в makefile (и тулзу для него), проще сделать удаление Code/Sym и перекомпиляцию с нуля. Скорость компиляции это позволяет.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Март, 2011 11:48 

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 7829
Откуда: Троицк, Москва
Евгений Темиргалеев писал(а):
Чем возиться с прописыванием зависимостей в makefile (и тулзу для него), проще сделать удаление Code/Sym и перекомпиляцию с нуля. Скорость компиляции это позволяет.
И это, вроде как, обычная практика, no?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Март, 2011 12:49 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2504
Откуда: Россия, Ярославль
И что, много тут "обычно практикующих" совместную разработку?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Март, 2011 13:23 

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 7829
Откуда: Троицк, Москва
Пётр Кушнир писал(а):
И что, много тут "обычно практикующих" совместную разработку?
Ну, граница между совместной разработкой и разработкой пары подсистем одним челом не столь однозначная.

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

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

Да и в одной рыхлой подсистеме из многих модулей постоянно имеет место аналогичный эффект.

Точно как Е.Т. предложил: стираешь целиком Com+Sym и перекомпилируешь.

Как я понимаю, роль мейка переходит упорядоченному списку модулей.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Март, 2011 13:29 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2289
Откуда: Россия, Санкт-Петербург
Пётр Кушнир писал(а):
И что, много тут "обычно практикующих" совместную разработку?
Да найдутся поди.
Пользуюсь GNU Make.
В ББ Com и Sym не стираю, просто завожу коммандер на полную перекомпиляцию подсистемы, и храню его в Docu/Sys-Map.odc. Там же рядом храню и коммандер на выгрузку всех модулей.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Март, 2011 13:41 

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 7829
Откуда: Троицк, Москва
Александр Ильин писал(а):
В ББ Com и Sym не стираю, просто завожу коммандер на полную перекомпиляцию подсистемы ...
Предпочитаю всё-таки стереть Com и Sym из-за того, что бывали накладки какие-то, если не стирать (насколько помню, когда добавляешь модули и т.п.).

Если стереть, то оно само сообщает, если накладка. Проще жить с чистого листа.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Март, 2011 14:08 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2504
Откуда: Россия, Ярославль
Пётр Кушнир писал(а):
либо, не рассматривать кодовые файлы как нечто постоянное и отважно удалять их, перекомпилируя ВСЮ систему в целом. Что может быть невозможным, при отсутствии исходников, либо, при наличии постоянно развивающихся исходников, либо, окажется неадекватным, вследствие необходимости передать малый пакет изменений системы О на рабочие места.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Март, 2011 14:30 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4485
Откуда: Россия, Орёл
Задачу поставьте конкретнее. Если я правильно понял, это "передать малый пакет изменений системы О на рабочие места". Чтобы посылать не все Code/Sym, а только изменённые.

Могу предложить такое "решение в лоб":
- держать полную копию эксплуатируемой на местах системе
- при появлении изменений, которые надо распространить, строите новую систему
- распространяете разницу, которую выдаст сравнение каталогов.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Март, 2011 15:06 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2504
Откуда: Россия, Ярославль
Задача распространения решена, так или иначе.
Я же не задачи ставлю, я проблему описываю. А мне предлагают УДАЛЯЙ @ КОМПИЛЯЙ.


Последний раз редактировалось Пётр Кушнир Пятница, 04 Март, 2011 15:12, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Март, 2011 15:08 

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 7829
Откуда: Троицк, Москва
Пётр Кушнир писал(а):
Пётр Кушнир писал(а):
либо, не рассматривать кодовые файлы как нечто постоянное и отважно удалять их, перекомпилируя ВСЮ систему в целом. Что может быть невозможным, при отсутствии исходников, либо, при наличии постоянно развивающихся исходников, либо, окажется неадекватным, вследствие необходимости передать малый пакет изменений системы О на рабочие места.

А. Виноват.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Март, 2011 15:19 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4485
Откуда: Россия, Орёл
Пётр Кушнир писал(а):
Задача распространения решена, так или иначе.
Я же не задачи ставлю, я проблему описываю. А мне предлагают УДАЛЯЙ @ КОМПИЛЯЙ.
Разве описание проблемы не есть постановка задачи, которой Вы хотите найти (лучшее) решение? Лично я из первого поста так и не понял толком, в чём заключается самая главная проблема...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Март, 2011 15:29 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4485
Откуда: Россия, Орёл
я про то, что распространение изменений внутри коллектива разработчиков и от разработчиков к заказчику это, по-моему, сильно разные задачи.

И для первой решение "удаляй@компиляй", по-моему вполне нормльное. Зачем ещё чего-то городить.?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Март, 2011 15:43 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2504
Откуда: Россия, Ярославль
потому что оно ощущается эмпирически. вот, прям в этот момент
Евгений Темиргалеев писал(а):
Лично я из первого поста так и не понял толком, в чём заключается самая главная проблема...
Пётр Кушнир писал(а):
В связи с этим хотелось бы осмыслить проблему вообще. Сформулировать, и всё такое.
как бы.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Март, 2011 15:46 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2504
Откуда: Россия, Ярославль
Пётр Кушнир писал(а):
потому что оно ощущается эмпирически. вот, прям в этот момент
Евгений Темиргалеев писал(а):
Лично я из первого поста так и не понял толком, в чём заключается самая главная проблема...
Пётр Кушнир писал(а):
В связи с этим хотелось бы осмыслить проблему вообще. Сформулировать, и всё такое.
как бы.

linux-way?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Март, 2011 18:02 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 2846
Откуда: Астрахань
Info21 писал(а):
Евгений Темиргалеев писал(а):
Чем возиться с прописыванием зависимостей в makefile (и тулзу для него), проще сделать удаление Code/Sym и перекомпиляцию с нуля. Скорость компиляции это позволяет.
И это, вроде как, обычная практика, no?

Среди виртовских сред - да. Еще в TopSpeed Modula-2 так делали.
Среди С/С++ и других - нет. Там мейкеры рулят.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Март, 2011 18:52 

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 7829
Откуда: Троицк, Москва
Валерий Лаптев писал(а):
Info21 писал(а):
И это, вроде как, обычная практика, no?
Среди виртовских сред - да. ..
А мы не про ББ? П.К. на ББ, кажись, работает. Что-то я запутался ...


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 21 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2018, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB