У меня есть 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. надо каждый раз не забывать настраивать эту переменную. Причем если забыл настроить, то переменная может указать на другую вытащенную на диск ветку и получится полная ж.

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

В файле проекта отсутствуют абсолютные пути.
Т.е. для конкретного проекта eclipse пляшет относительно каталога в котором лежат файлы ".cproject" и ".project".

согласен, но только "вниз". А вверх - не получается.
Т.е. если у меня структура:

то по-идее путь к sources будет ..\sources. Однако eclipse на такой путь говорит, что он не существует, а если папку все равно создать и посмотреть в свойствах, то там будет адрес c:\sources....

Когда мне такое нужно, то я делаю :
"NewFolder->Advanced->Link to folder int the file system"

И соответственно создается виртуальное имя которое привязано к абсолютному пути.

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


И кстати, настройки воркспейса - хоткеи и т.д. можно как-то "расшарить" между несколькими ворксейсами?

В workspace хранятся общие настройки (позиции диалогов, цвета для подсветки текста, клавиатурные настройки).
Переменные и настройки проекта хранятся в файлах ".cproject" и ".project" которые создаются в каталоге проекта.
Т.о. когда вы кнопочкой Del удаляете проект из Project Explorer'а, то все намеки на проект напрочь удаляются из workspace. Однако ".cproject" и ".project" не удаляются (ну разве что укажете удалить содержимое проекта), и поэтому можно полностью восстановить проект в eclipse через "File->Import->Existing proect".

К примеру, я, при первом запуске eclipse указал ему запихать свой workspace подальше с моих глаз.
Теперь, когда создаю новые проекты то прямо указываю в каком каталоге будет создан новый проект.
И есстественно, что настройки сохраняемые в workspace "шарятся" между всеми проектами.

Насколько я понял из хелпа и экспериментов, path variables хранятся в workspace (вкладка windows\preferences\general\workspace\linked resources).

У меня несколько директорий с проектами, типа:
test1
test2
test3
src
inc

workspace для них в корне дерева
В makefile прописано где src (общие исходники для нескольких проектов) и хедеры (inc) и проекта файлы
Переключаюсь между проектами в среде
Для общей сборки всех проектов (типа релиза) имеется отдельный cmd-файл (можно сделать bat для winxx, для Linux можно написать скрипт на чем-либо (bash и т.д.) )

А в eclipse у вас src, inc - проекты? Или вы в каждый проект добавили папки со ссылками на них?
Если папки - то пути абсолютные или относительные?

И еще вопрос - вы системой контроля версий пользуетесь? Файлы проекты eclipse у вас тоже в ней лежат или как?

PS Для общей сборки использую scons, тут все ок.

Рабочие проекты test1-test3.
scr общая часть кода для этих проектов (общая инициализация, драйвера устройств и т.д.),
inc общие заголовочные файлы (*.h)
в makefile сделаны соответствующие ссылки на src и inc (проекты на работе, не помню точно какие пути (в смысле абсолютные или относительные)). Некоторая пляска с бубном была из-за src, чтобы правильно бралось (изучение документации по make сильно помогло)
системой контроля версий не пользуюсь (а надо бы)

Это понятно. Мне интересно - как у вас к eclipse-проекту test1 подключена общая часть - src и inc?

Это касается только linked resources общих для всего workspace.
Те linked folders, пример которых приводился ранее, касаются только конкретного проекта и хранятся исключительно в файлах описывающих проект (.project & .cproject).

Собственно вопрос таков - как включить в проект файлы, лежащие "над" проектом eclipse без использования абсолютных путей.
Я пробовал linked folders, однако они привязываются либо к абсолютному пути, либо к переменной workspace...

Все прописано в makefile, в парсере Eclipce эти заголовочные файлы доступны для просмотра и редактирования. Все на работе, в понедельник могу кусок makefile с этой конфигурацией прислать.

Меня интересует именно подключение к Eclipse - как оно у вас сделано?
Т.е. у вас есть eclipse-проект test1, как вы к нему подключили src и inc, чтобы Eclipse их видел и обрабатывал парсером?

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

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

К сожалениию, это работает только в 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 при создании проекта неудается добится такогоже содержимого при создании проекта