LightElf (06.10.2015 08:22, просмотров: 145) ответил VL на Потому что код совпадает на 2/3. А если разные компиляторы под разные процессоры, тоже есть варианты, но это уже притянуто за уши. А workspace - не притянут.Не надо делать мне как лучше, оставьте мне как хорошо
-
- А как это все организовано с учетом контроля версий? - 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,