VL (02.10.2015 18:54, просмотров: 1) ответил LightElf на Если совсем коротко - заколебало вести глобальный хидер с енумом.-
- Ну вот собственно и нашел в конце-концов решение в виде: LightElf(571 знак., 02.10.2015 19:01 - 19:06)
- Вам виднее, но по моему, с точки зрения документирования проекта, это тихий ужас. Тем более что Хэш не гарантирует уникальности. - Скрипач(02.10.2015 20:29)
- С точки зрения документирования, да и вообще сопровождения, проекты в одном 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)
- Можно, конечно, сделать вид, что существуют "архитектурно независимые" части, но это, скорее, иллюзия. Простейший пример - размеры целых типов. SciFi(36 знак., 07.10.2015 11:49 - 11:51)
- Дык не надо общие сорцы "подпиливать на Cortex". На Cortex надо подпиливать только архитектурно-специфичные части, которые живут в своем собственном подкаталоге. Если возникла необходимость изменить общие сорцы в связи с новой архитектурой - это LightElf(38 знак., 07.10.2015 11:47)
- Вот и у меня практически так же, кстати есть аналогичный опыт MSP430 + Cortex, но "всегда компилится самая свежая версия" - это засада. Месяц назад заказчик захотел в одном проекте рюшечки одной версии, а в другом - рюшечки другой версии, тут я и VL(244 знак., 07.10.2015 13:17,
- Да особо никак. Общие сорцы лежат в отдельном каталоге, откуда подтягиваются в проекты. Таким образом всегда компилится самая свежая версия общей части (HAL, протоколы, стек). В каждом конкретном проекте есть заголовочный файл, в котором дефайнами LightElf(148 знак., 07.10.2015 11:22)
- А как это все организовано с учетом контроля версий? - VL(06.10.2015 21:45,
- Ничего не притянуто. Из одних сорцов компилится тремя компиляторами: под HCS12, Coldfire и Cortex M. Есть шансы, что еще RX будет. Какой уж тут workspace. - LightElf(06.10.2015 08:22)
- Потому что код совпадает на 2/3. А если разные компиляторы под разные процессоры, тоже есть варианты, но это уже притянуто за уши. А workspace - не притянут. - VL(05.10.2015 16:50,
- А зачем их делать в одном workspace? А че делать, если используются разные компиляторы под разные процессоры? - LightElf(05.10.2015 08:37)
- С точки зрения документирования, да и вообще сопровождения, проекты в одном workspace (термины IAR) - вообще ( . ). Не далее, как вчера, сам огрёб. - VL(03.10.2015 06:32,
- Вам виднее, но по моему, с точки зрения документирования проекта, это тихий ужас. Тем более что Хэш не гарантирует уникальности. - Скрипач(02.10.2015 20:29)
- Ну вот собственно и нашел в конце-концов решение в виде: LightElf(571 знак., 02.10.2015 19:01 - 19:06)