caxapa.ru :: Вам виднее, но по моему, с точки зрения документирования проекта, это тихий ужас. Тем более что Хэш не гарантирует уникальности.

Скрипач, пророк (02.10.2015 20:29, просмотров: 134) ответил LightElf на Ну вот собственно и нашел в конце-концов решение в виде:

Вам виднее, но по моему, с точки зрения документирования проекта, это тихий ужас. Тем более что Хэш не гарантирует уникальности.

... но не любой ценой.

Ответить

- С точки зрения документирования, да и вообще сопровождения, проекты в одном workspace (термины IAR) - вообще ( . ). Не далее, как вчера, сам огрёб. - VL(03.10.2015 06:32, )
  - А зачем их делать в одном workspace? А че делать, если используются разные компиляторы под разные процессоры? - LightElf(05.10.2015 08:37)
    - Потому что код совпадает на 2/3. А если разные компиляторы под разные процессоры, тоже есть варианты, но это уже притянуто за уши. А workspace - не притянут. - VL(05.10.2015 16:50, )
      - Ничего не притянуто. Из одних сорцов компилится тремя компиляторами: под HCS12, Coldfire и Cortex M. Есть шансы, что еще RX будет. Какой уж тут workspace. - LightElf(06.10.2015 08:22)
        
        А как это все организовано с учетом контроля версий? - VL(06.10.2015 21:45, )
        
        Да особо никак. Общие сорцы лежат в отдельном каталоге, откуда подтягиваются в проекты. Таким образом всегда компилится самая свежая версия общей части (HAL, протоколы, стек). В каждом конкретном проекте есть заголовочный файл, в котором дефайнами LightElf(148 знак., 07.10.2015 11:22)
        
        Вот и у меня практически так же, кстати есть аналогичный опыт MSP430 + Cortex, но "всегда компилится самая свежая версия" - это засада. Месяц назад заказчик захотел в одном проекте рюшечки одной версии, а в другом - рюшечки другой версии, тут я и VL(244 знак., 07.10.2015 13:17, )
        
        Третий месяц пытаюсь свести в один проект программные модули которые когда-то росли из одного места, но затем много лет развивались в разных проектах. Это оказалось неожиданно большой проблемой - вроде бы вот оно, все что нужно, но оно упорно не AlexG(23 знак., 07.10.2015 18:15)
        
        У меня задачи достаточно узкие. Все рюшечки общего кода старых версий доступны для новых версий. Старый функционал полностью сохраняется. Это временами огорчает (приходится поддерживать некоторые старые косячные опции параллельно новым прямым), но LightElf(293 знак., 07.10.2015 13:57)
        
        "Свежая версия общей части" - это мощно. Скажем, подпилили сорцы на Cortex, добавили баг, который проявляется только на Coldfire, и спокойно пошли пить чай. Красота! - SciFi(07.10.2015 11:28)
        
        Дык не надо общие сорцы "подпиливать на Cortex". На Cortex надо подпиливать только архитектурно-специфичные части, которые живут в своем собственном подкаталоге. Если возникла необходимость изменить общие сорцы в связи с новой архитектурой - это LightElf(38 знак., 07.10.2015 11:47)
        
        Можно, конечно, сделать вид, что существуют "архитектурно независимые" части, но это, скорее, иллюзия. Простейший пример - размеры целых типов. SciFi(36 знак., 07.10.2015 11:49 - 11:51)
        
        Размер целых типов прекрасно описывается в stdint.h Индейцы тоже легко обходятся макросами вида U32_TO_LE(), U16_FROM_BE() и т.д. - LightElf(07.10.2015 11:59)
        
        Естественно. Ну так вот, забыл на минутку про stdint.h или U32_TO_LE(). На Cortex работает, а на HCS12 заглючит. Что и требовалось доказать. - SciFi(07.10.2015 12:04)
        
        Это просто вопрос привычки. Если при переносе на новый камень возникла нужда править, например, код USB бутлодера - это, вообще говоря, тревожный звоночек. Значит там что-то непродумано, стоит взять паузу и еще раз поразмыслить. Последний раз LightElf(55 знак., 07.10.2015 12:20)

Средства и методы разработки