У меня есть svn-репозиторий с примерно такой структурой:

common1, 2 и т.д. - общие файлы, используемые во многих проектах. proj1 - папка проекта. В ней папки с исходниками, докой и файлами редактора (сейчас использую слик). В ветках и тагах структура такая же.
Хочу переползти на eclipse. И не понятно, как "прикрутить" сюда его проекты. Со сликом все просто - в проекте лежат пути относительно файла проекта, т.е. выгружаю всю нужную мне ветку в папку на винте и все работает.
В eclipse, насколько я понял, все пляшет относительно workspace, в частности в ней хранятся настройки клавиш, окошек и т.д. Т.е. желательно иметь одну общую workspace на все проекты.
Если я создаю проект еклипса в папке proj1\eclipse, то чтобы добавить в него файлы из proj1\sources и common1, 2..., мне надо использовать папки, привязанные к файловой системе (linked resources). Можно использовать переменные, однако для них надо задать абсолютные пути.
Т.е. у меня получается, что в каждой ветке лежит своя workspace, в ней заведена переменная pathToBrunch, в каждом проекте лежит папка eclipse (с проектом), пути в котором заданы относительно pathToBrunch. После checkout-а ветки на диск надо руками настроить эту переменную.
В этом подходе мне не нравится:
1. Мои личные настройки внешнего вида eclipse лежат в svn. Причем они разные по каждой ветке - т.е. если я перенастроил хоткеи в trunk и затем извлек какую-то старую версию, то хоткеи там будут старыми...
2. надо каждый раз не забывать настраивать эту переменную. Причем если забыл настроить, то переменная может указать на другую вытащенную на диск ветку и получится полная ж.

Вобщем, если кто поделится личным опытом по этой теме, буду признателен.

Так вроде ж : ${workspace_loc:/имя проекта} указывает в коневой каталог самого проекта.

Вот тут описание :
http://publib.boulder.ibm.com/infocenter/w...s/cexttools.htm

Сообщение отредактировал YKonstantin - Feb 10 2008, 12:23

К сожалениию, это работает только в external tools. Указать так путь в linked folder нельзя. В частности, если написать ${workspace_loc} и посмотреть потом в свойства ресурса, то там будет C:\${workspace_loc}...

Судя по всему проекты eclipse заточены на то, чтобы весь код лежал "внутри" проекта...

Позволю себе с вами не согласиться.
Веду несколько проектов со следующей структурой каталогов :
\
|--Platform
||-arm
||-pc
|-System

В arm создан проект компилирующийся для ARM7, к нему линком на каталог присоеденен System содержащий всякие менюшки и собственно файл содержащий "int main(void)".

В pc создан проект компилирующийся для ПК (ОС Windows), к нему линком на каталог присоеденен System содержащий всякие менюшки и собственно файл содержащий "int main(void)".

Т.е. имеется одно устройство и два проекта.

Линком с абсолютным путем? Очень неудобно, особенно если проект лежит в репозитории и одновременно работаем с разными версиями проекта.
Линком через path-переменную workspace? Те же грабли - path-переменные задаются только на абсолютные пути.

Странно, что нет возможности подключить файлы\папки по относительным путям "вверх" от проекта...

Ну, я привык, что новую версию надо заводить в случае кардинальных изменений в требованиях.
Например добавили энкодер, или от 5-ти кнопок оставили 2-3.
Поэтому достаточно завести новый каталог, скопировать туда уже существующий проект, в файлах ".cproject" и ".project" изменить пути и название проекта, и всё это новообразование считать новым проектом.
Согласитесь, что изменение в органах управления или в системе меню (устройство для заказчика X переделать для заказчика Y) достойно вывода в отдельный проект. Само собой, что одинаковые для всех проектов модули (вроде присловутого delay.c или bcd.c) можно расшаривать между всеми проектами, однако в случае передачи исходных текстов одного из проектов "на сторону" придется тащить за ним весьма сложную и избыточную структуру, что скорей всего приведет, извините к геморрою эдак 4-й стадии.

Хотя все выше приведенное есть ИМХО, поскольку я использую SVN только для контроля изменений вида "а что это я когда-то тут правил", а т.ж. для того чтобы иметь некий список произведенных работ и исправленных ошибок.

интересно, а кто мешает на общие части проекта сделать библиотеку?
И уже ее цеплять(линковать) к каждому проекту?

это идея Спасибо, попробую.


Попробовал - вроде ок.
Получается примерно так -


to YKonstantin:
у меня процесс разработки выглядит немного по другому - я создаю новую ветку всякий раз, когда прошивка уходит на тестирование. Ошибки, найденные при тестировании, правятся в этой ветке, а в основной ветке работа продолжается. Просто иногда тестирование занимает длительное время, соответственно к концу тестирования его приходится начинать заново - слишком много новых изменений.
Т.е. у меня вполне штатно идет работа с несколькими ветками одного проекта, вот и пытался придумать, как втиснуть это в eclipse.
Что касается гемора с передачей проекта на сторону - не могу ничего сказать, не сталкивался. Подозреваю, что мне проекты придется передавать только в случае перехода на новую работу - слишком уж они "тяжелые" ...

У меня
.metadata
в корне дерева каталогов проекта

В makefile
EXTRAINCDIRS = ../inc
для хедеров

source_dirs := . ../src
для исходных текстов, общих для проектов

Особенность с флагами компилятора:
если все исходные тексты в рабочей директории
CFLAGS += -Wa,-adhlns=$(<:%.c=$(OBJDIR)/%.lst)

если в разных (в src и рабочей)
CFLAGS += -Wa,-adhlns=$(OBJDIR)/$(notdir $(<:%.c=$(OBJDIR)/%.lst))

Сделано для того, чтобы obj правильно располагались и брались.

Вот насчет папки с workspace.
Нет нужды ее холить и лелеять. Потому как при переходе к новой версии eclipse+cdt есть официальная рекомендация создавать workspace заново.
У меня есть опыт перехода, и было это так :
Eclipse стоит у меня не на системном диске, поскольку тот за-backup'лен, и может быть восстановлен "в ноль" когда мне захочется. Eclipse же не пользуется системным реестром и поэтому его не обязательно привязывать к текущему состоянию ОС. При первом запуске, на вопрос где держать workspace, я ответил "eclipse\workspace".
Когда пришло время установить связку eclipse+cdt более свежей версии, я посмотрел по конфигурационным файлам, и отобрал те из них где описывались подсветки, клавиатура и т.п. Сохранив эти файлы, я удалил каталог eclipse (вместе с workspace), а после установки новой версии скопировал старые файлы поверх новых. Т.о. получился новый eclipse со старыми настройками.

На основе приведенного личного опыта можно сделать вывод, что нет смысла организовывать работу с проектами относительно каталога с workspace.

я так вообще просто выложил весь workspace в svn-репозиторий и каждый раз обновлюсь при загрузке на очередной машине. Если сети нет то перетаскиваю на флешке.

лично у меня про eclipce есть одна тонкость - когдато на старой eclipse+cdt сделал простой make-проект (неавижу умные системы) - при билде вызывается только make $(TARGET) без всяких внутренних билдеров. Так вот этот проект (а посути это набор файлов .cdtproject .cproject .project) я использую как скелет для начала проекта. свежими CDT при создании проекта неудается добится такогоже содержимого при создании проекта