Как прописать путь к файлу?, IAR AVR Опции

[fmdost]

Доброго времени суток Уважаемые.
Есть 2 проэкта с одним kommand_descript.h Пытаюсь поставить полный путь, в ответ получаю ругань.
Можно ли как в досе? Типа не весь путь а только переход из папки в папку. Правда напрочь забыл, как это в досе делается.
Желательно типа так:
с:\xx\xx\трагет_фолдер\проэкт1\ сдесь лежит весь проэкт1
с:\xx\xx\трагет_фолдер\проэкт2\ сдесь лежит весь проэкт2
с:\xx\xx\трагет_фолдер\общие_файлы\ сдеесь лежит kommand_descript.h
Сильно не пинайте. Спасибо!

Сообщение отредактировал Т.Достоевский - Oct 16 2007, 23:01

[dxp]

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

[Dog Pawlowa]

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

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

[Andy Mozzhevilov]

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

А в чем сложность, собственно?

[Dog Pawlowa]

А в чем сложность, собственно?

То ли я не умею готовить, но у меня вот эти две папки
|->_INC <-общие хидеры проектов
|->_SRC <-общие исходники проектов
не получаются статическими, они тоже изменяются. В реальной жизни то ошибка находится, то ли стремление улучшить проснется.

Получается такая последовательность:
- общая часть ver 1
- проект A ver 1
- проект B ver 1
Произвели 100 устройств проекта A.
- корректировали общую часть ver 2
- корректировали проект 2
Произвели 100 устройств по проекту B.
Корректировали проект A ver 2.
Произвели 100 устройств проекта A
Пришла жалоба от клиента по ошибке в проекте A из первой партии.
Начинаем разбираться. Вернули версию проекта A на 1 - все правильно. Но результат компиляции другой, так как была изменена общая часть. Концов не осталось.

[Andy Mozzhevilov]

То ли я не умею готовить, но у меня вот эти две папки
|->_INC <-общие хидеры проектов
|->_SRC <-общие исходники проектов
не получаются статическими, они тоже изменяются. В реальной жизни то ошибка находится, то ли стремление улучшить проснется.

Получается такая последовательность:
- общая часть ver 1
- проект A ver 1
- проект B ver 1
Произвели 100 устройств проекта A.
- корректировали общую часть ver 2
- корректировали проект 2
Произвели 100 устройств по проекту B.
Корректировали проект A ver 2.
Произвели 100 устройств проекта A
Пришла жалоба от клиента по ошибке в проекте A из первой партии.
Начинаем разбираться. Вернули версию проекта A на 1 - все правильно. Но результат компиляции другой, так как была изменена общая часть. Концов не осталось.

В общем, может это уже и не в топик данной темы, но все же отвечаю.
Чтобы такого как у вас не случалось, общие части, которые могут быть использованы в разных проектах должны в каждом проекте иметь свои локальные копии, находящиеся под контролем системы CVS (или подобной).
Именно система контроля версий и позволяет это сделать достаточно безболезненно, а вот если вы не пользуете систему контроля версий, тогда действительно синхронизировать общие исходники для разных проектов - тот еще гемор.
В этом случае будет примерно так:
- выпустили релиз проекта A ver 1 "А1" (с общей частью "common 1")
- выпустили релиз проекта В ver 1 "В1" (с общей частью "common 1")
"А1" и "В1" здесь надо воспринимать как тэги, однозначно идентифицирующие набор всех файлов проекта, как из common части, так и из файлов, относящихся исключительно к проекту.

Произвели 100 устройств проекта A, релиз "А1".

- корректировали общую часть на "common 2" в проекте В.
- выпустили релиз проекта В ver 2 "В2" (с общей частью "common 2")
Произвели 100 устройств по проекту B, релиз "В2".

- приступили к коррекции проекта "А", до кучи обновили common часть на "common 2".
- выпустили релиз проекта А ver 2 "А2" (с общей частью "common 2")
Произвели 100 устройств проекта A, релиз "А2".

Пришла жалоба от клиента по ошибке в проекте A с релизом "А1".
Начинаем разбираться. Извлекли версию проекта а по тэгу релиза "А1".
В локальной копии будут присутствовать исходники common версии "common 1".
Результат компиляции до байта совпадает. Конец найден, и виноватый тоже

И если проект ведет более, чем один программист, то данная концепция просто необходима. Система контроля версий это конечно хорошо, но согласованность при разработке в команде важнее.
P.S. конечно в проектах, которые выполняю единолично, я позволяю себе больше вольностей

Если проект ведет более чем один программист система контроля версий - суровая необходимость.
Иначе:
- Вася, ты менял исходник в таком то каталоге?
- Да, тебе кинуть?
- Конечно, еще месяц назад надо было.
- Да я же в отпуске был. Блин, сетевой каталог не открывается, давай флешку...

[Dog Pawlowa]

Конец найден, и виноватый тоже

Ну, с виноватыми обычно проблем не бывает
Признаюсь, инструкцию по SVN курил "не в затяжку", пользуюсь очевидными функциями. Про такую комбинацию не думал.
Мне кажется, что могут быть проблемы, если отмотать версию в такой локальной копии common назад и случайно закоммитить. Но нужно подумать и попробовать. Спасибо.

[Andy Mozzhevilov]

Ну, с виноватыми обычно проблем не бывает
Признаюсь, инструкцию по SVN курил "не в затяжку", пользуюсь очевидными функциями. Про такую комбинацию не думал.
Мне кажется, что могут быть проблемы, если отмотать версию в такой локальной копии common назад и случайно закоммитить. Но нужно подумать и попробовать. Спасибо.

Я пользуюсь на данный момент CVS, как оно реализуется в SVN не совсем представляю, поскольку доку по SVN меня несколько насильно заставили покурить некоторые присутвующие в том числе здесь товарищи . И в данный момент она недокурена пока.
В CVS при извлечении по тэгу локальную версию закомитить будет нельзя, поскольку на ней будут так называемые липкие метки. Если нужно будет, допустим, выпустить релиз на основе именно этой комбинации исходников, ну типа исправить только тот небольшой баг, то тогда делается ветвь в проекте на основе текущей версии извлеченных исходных текстов и она уже комитится, но не мешает основному стволу разработки. При желании потом изменения можно внести на ствол.

[dxp]

Я пользуюсь на данный момент CVS, как оно реализуется в SVN не совсем представляю, поскольку доку по SVN меня несколько насильно заставили покурить некоторые присутвующие в том числе здесь товарищи . И в данный момент она недокурена пока.

Вот и плохо! Но тебя раззи заставишь, если ты не хошь...

В CVS при извлечении по тэгу локальную версию закомитить будет нельзя, поскольку на ней будут так называемые липкие метки. Если нужно будет, допустим, выпустить релиз на основе именно этой комбинации исходников, ну типа исправить только тот небольшой баг, то тогда делается ветвь в проекте на основе текущей версии извлеченных исходных текстов и она уже комитится, но не мешает основному стволу разработки. При желании потом изменения можно внести на ствол.

В Subversion принципиально это не отличается.