Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: SVN и IAR вопрос новичка.
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Управление проектами
shreck
У меня есть iar'овский проект. Хочу, чтобы под контроль версий попадали не только исходники, но и файлы проекта (*.ewp, *.eww, *.ewd и т.д.). Я посмотрел их содержимое и меня смутило такое явление: часть путей прописаны относительно рабочей папки, а часть - задана в виде полного пути. Я подумал - здесь могут быть проблемы для контроля версий.

Далее я сделал следующее.
Исходно мой проект размещался в C:\Projects\MyPrj\, где находились папка Src со всеми исходниками и iar'овские файлы с настройками среды и проекта.
Далее, следуя руководству по svn, я скопировал файлы проекта в отдельный каталог для его дальнейшего импорта в хранилище - C:\Temp\MyPrj. После чего сделал импорт. Все хорошо импортировалось.
Далее, я выполняю check out для получения рабочей копии в папку C:\ProjectsSVN\MyPrj. Пока все хорошо.
Но после запуска iar'a начались неприятности. Во-первых, открытые файлы были открыти из C:\Projects\MyPrj\. Во-вторых, при запуске make вылезла ошибка - Build error: Multiple tools write to the same file.

Т.е. получается, насколько я представляю, некий конликт с файлами, расположенными в C:\Projects\MyPrj\ и все это из-за полностью прописанных путей в файлах iar'a.

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

Кто что может подсказать?
Doka
Цитата(shreck @ May 30 2007, 12:23) *
...часть путей прописаны относительно рабочей папки, а часть - задана в виде полного пути. Я подумал - здесь могут быть проблемы для контроля версий.
это ваши проблемы, а не контроля версий.


Цитата(shreck @ May 30 2007, 12:23) *
Исходно мой проект размещался в C:\Projects\MyPrj\, где находились папка Src со всеми исходниками и iar'овские файлы с настройками среды и проекта.
...
Далее, я выполняю check out для получения рабочей копии в папку C:\ProjectsSVN\MyPrj. Пока все хорошо.
..
открытые файлы были открыти из C:\Projects\MyPrj\.
естественно! SVN ничего не знает и не должно знать о ваших путях и ваших настройках проекта..

Цитата
еВообщем, мне бы хотелось иметь контроль версий не только для сырцов, но и для служебных iar'овских файлов, чтобы когда я вынимаю, скажем ревизию N, то правильно бы вынулись и настройки среды и проекта. Причем это должно выполнятся для любого каталога, куда я делаю рабочую копию.
выходом могло бы служить использование тега $URL, но проблема в том, что он перекрестно ссылается на последнюю ревизию (т.е. в рабочей копии прописан репозиторий, а в репозитории - локация последнего checkout)
поэтому наверное только ручками можно сделать что вы хотите - завести для репозитария хитрый таг, и скрипт, который при co и ci соотеветственно делать подмену на текущий путь [pwd] и наоборот. (хотя может существовать какое-то более элегантное решение)
spf
Цитата(shreck @ May 30 2007, 14:23) *
Кто что может подсказать?

Переконфигурируй проект IAR - используй только относительные, он может работать с такими путями.



Цитата(Doka @ May 30 2007, 14:43) *
хотя может существовать какое-то более элегантное решение
Конечно есть smile.gif -- использовать альтернативный инструмент для сборки проекта (make/scons/cook).
Doka
spf
ну да.. относительные пути - это, конечно, идеальное решение
shreck
После некоторых ковыряний способ достичь желаемого все-таки нашелся. Как обычно, ларчик открывается просто, причем в дебри svn'a лезть не надо.

Создаем рабочую копию в любом удобоваримом месте диска. Запускаем iar, после чего выполняем Project->Clean. После этого все становится на свои места и работает как положено.
Сергей Борщ
Цитата(shreck @ May 30 2007, 15:32) *
Создаем рабочую копию в любом удобоваримом месте диска. Запускаем iar, после чего выполняем Project->Clean. После этого все становится на свои места и работает как положено.
Я использую всегда относительные пути (в настройках пректа использую "макросы" $PROJ_DIR$, $TOOLKIT_DIR$). И еще - я перед импортированием проекта стираю *.dep и папки settings, Debug, Release и заношу их в svn:ignore - *.dep и Debug, Release создаются каждый раз при компиляции проекта и совершенно незачем хранить их в репе, то же и с папкой settings - там хранятся расположение окон, панелей на окнах, список открытых файлов. Вернуть эти настройки после импорта можно раскидав привычно окна буквально в течении 10 секунд, но зато эти файлы не засоряют реп - они меняются практически при каждом запуске оболочки. Если проект уже импортирован, то после добавления этих папок в svn:ignore их нужно удалить из проекта через svn del
spf
Существует глобальный ignore. Под windows задается в файле "C:\Documents and Settings\%имя пользователя%\Application Data\Subversion\config"
Код
global-ignores = *.o *.obj *.d *.*~ *~
shreck
Цитата(Сергей Борщ @ May 30 2007, 22:09) *
Я использую всегда относительные пути (в настройках пректа использую "макросы" $PROJ_DIR$, $TOOLKIT_DIR$). И еще - я перед импортированием проекта стираю *.dep и папки settings, Dug, Release и заношу их в svn:ignore...

Собственно говоря, я именно так и сделал (за исключением того, что *.dep и settings я включил в хранилище). Поэтому и был удивлен, когда увидел в этих файлах проекта полные пути. Но видимо это какие-то артефакты, потому что после clean абсолютные пути исчезают и остаются только относительные.



Цитата(spf @ May 31 2007, 00:08) *
Существует глобальный ignore. ...

Глобальный он и есть глабальный. Не всегда это удобно и приемлемо.
dxp
Цитата(shreck @ May 31 2007, 10:20) *
Глобальный он и есть глабальный. Не всегда это удобно и приемлемо.

Ничего не мешает использовать локальные игноры. Глобальный - он только лишь для того, чтобы уменьшить работу при создании локальных, когда сразу ясно, какие файлы всегда точно надо игнорировать.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.