Имам workspace в който вече има един проект с настроени toolchain, setting-и и т.н. Самите сорсове стоя на SVN repository.
Сега искам да добавя в workspace-а втори проект, който реално вече съществува на SVN URL, но е за друго IDE. Като го добавя в еклипса тоя втори проект искам да копирам вече настроените сеттинги от първия проект - всичко от "C/C++ Build" node-а в properties на проекта (или поне Environment и Settings, или в краен случай поне Settings). Там са ми настройките на инструментите, командните опции за компилатор и линкер и т.н.

Пробвах с "Export" "C/C++ Project settings" - и после Import -> прехвърля само дефинираните символи и Include пътища.
Не става с копиране на .cproject и подобни - вътре има някакви идентификатори на проекта и на инструментите, които са различни за всеки проект.

Някой да има идея какво мога да направя (освен ръчно прехвърляне)? Проектите, които мигрирам са няколко и не искам да го правя ръчно, основно за да не пропусна нещо.

не ми е известен такъв начин за прехвърляне...

Но честно казано никога не съм търсил, защото настройките на един еклипс проект са много специфични. Имал съм ядове, затова карам тук колегите да не слагат нищо в еклипса, както и да не качват настройките му (.cproject и т.н.) в SVN/CVS. Така всеки може да си направи чекоут на кой да е проект. След сваляне проекта по подразбиране е general и трябва да се пусне едно convert to C/C++ project.
Остава тук-таме някоя настройка да се направи ръчно, ама не са много защото същинските настройки по компилиране/линкване си ги държим в мейкфайлове.

Проблемът е това че имаме по няколко проекта за една платформа. За всеки от тези проекти настройките на компилатора са еднакви, но определено не са само няколко - като гледам са 20-тина неща в най-добрия случай (компилатор, линкер). Отделно пропускането на някоя от тях при ръчно настройване е крайно неприятно - проекта се билдва, но някъде може да изгърми по-късно - например alignment настройки, пък ако щеш дори нива на оптимизации.

За другото IDE имаме темплейтен проект, на база на който се почват нови проекти (за тази платформа). Само че там сме свикнали да е ръчно понеже самото IDE няма вграден SVN клиент.
Сега не започваме от нулата, а импортваме в еклипса проекти от другото IDE.
При еклипса нещата са по-елегантни с Subclipse-а. Имаме инсталация на еклипса с включени плъгини и toolchain. Т.е. всичко специфично е настроено в самия проект и е достатъчно да се направи: File->New->SVN и да се даде URL-a. После излиза warning че на SVN-a има вече .settings, .project и .cproject, които ще презапишат локалните. И съответният разработчик получава всички настройки и сорсове автоматично. Свободен е да използва произволен (свой, вече наличен с други проекти, за други платформи) workspace.

По принцип това мигриране се прави еднократно, и съответно само от мен, така че по никакъв начин не пречи на удобството на останалите (20+) човека да си работят без да знаят как са мигрирани проектите.
Трябва ми автоматизиран начин не за да спестя работа, а за да съм спокоен че съм прехвърлил всичко. Иначе за всеки проект трябва да изтествам всичко покрай миграцията.

Ок, разбирам че няма такъв стандартен начин, и се сещам защо е така - архитектурата на еклипса и CDT, и на toolchain плъгина води до това неудобство. Ще го направя ръчно.

Благодаря за отговора.

Долу-горе разбирам че нещо ви куца в организацията

Но не знам подробности, затова ще се въздържа от конкретни препоръки... Ще кажа само как съм го организирал аз. Значи всичко свързано с компилации се управлява от мейкфайла и поредица мк-файлове. Там е всичко необходимо, при това те са текстови файлове дето вървят с проекта и са качени в репозиторито. Няма как да стане грешка. Дори някой нещо да пипне като се синхронизира със сървъра веднага се вижда кои настройки къде са пипнати. По подобен начин стои и въпроса с дебъгването. В случая сме улеснени щото ползваме GDB, а той поддържа .gdbinit файл, където си слагаме най-важните неща...

В крайна сметка в Еклипс остават съвсем съвсем малко неща. За компилация/линкване почти нищо освен да извика make (което той прави по подразбиране за Ц/Ц++ проекти). За дебъгване трябва да се укаже ехе-то на GDB, ама то това е различно на всяка машина. Трябва да се укаже jtag/swd емулатора. Ама това са все уникални неща като локални пътища, IP-адреси и т.н. дето така или иначе НЕ ИСКАШ да се копират от компютър на компютър.

Всичко, което е универсално и важи за всички е в ТЕКСТОВИ конфигурационни файлове. Нищо важно не слагаме по wizard-и или диалози където и да е било. Текстовия файл вече знаеш е много лесен както за синхронизиране, така и търсене, промяна и т.н.

Сега, един проект почти винаги се налага да има много варианти (било щото хардуерно има няколко ревизии/опции на платките или щото софтуерно клиентите искат различни функции). Та за целта във всеки проект си правим една директория targets и в нея за всяка конфигурация си правим поддиректория. В поддиректорията слагаме всички конфигурационни файлове за дадената опция.
Останалите директории от проекта са така да се каже "универсални", демек там има сорсове организирани по някаква логика на модулен принцип. Но дали даден модул изобщо ще участва в компилацията и как ще участва си зависи от конфигурационните файлове.
Всичко това се вързва много добре с Еклипс. Значи като дръпнеш един проект веднага виждаш в targets колко вариации има. След това отиваш в опциите на проекта и в C/C++ build-> Manage Configurations си създаваш толкова конфигурации с колкото искаш да работиш. За всяка конфигурация после трябва да се сложи само един параметър при извикване на meke all/clean и това е името на конфигурационната директория. След това конфигурациите се появяват като опции на бутона с чукчето. По подобен начин се настройват и дебъг конфигурациите (бутона с бъг-чето).

После е супер лесно - до бутоните с чукчето и бъгчето има падащо меню, от което може да си избереш коя конфигурация да компилираш или дебъгваш.... Но още веднъж подчертавам, че важните опции са в конфигурационните файлове. Опциите на еклипса са само с декоративни функции... колкото да укажеш с коя конфигурация да бачкат чукчето и бъгчето

С мейкфайла ти се налага да правиш допотопно текстово редактиране в текстов файл/файлове, което тотално можеш да избегнеш ако използваш managed проект. Единствената причина човек да държи да остане на makefile би било за да прескочи бъгове в CDT-то, ама засега не ни се е налагало такова нещо (е, май сега ни се налага )... Сигурно разните automake, configure и подобни могат да решават тия неща, ама защо да не е лесно и удобно?
Отделно като ползваш SVN всичко ти се опреснява автоматично - като добавиш файл във версията, на следващия ъпдейт хората го получават и директно влиза да се компилира в проекта. Това става и външен мейкфайл, само че не виждам предимството?




Как така различно на машините - при правилната организация всичко си се знае къде е. Имаме си инсталация на еклипса, която качва и съответните toolchain-и и допълнителни глезотии. Настройката на префикса на компилаторите и пътищата са в проекта, и са релативни спрямо home-а на еклипса? Няма нищо "специфично локално", не се чудиш кое откъде се вика и коя версия е. Не търсиш проблем защо тестваната версия работи добре, а на клиента ми бие ексепшън (заради различна версия на инструмент например... - щото някой се хванал да ъпдейтне някоя си програма, дето иска cygwin, или нещо друго, сменила пътя, компилирало боза и върви го търси). Или понеже стандартните библиотеки се сменили.

Целта е да има абсолютна повтаряемост навсякъде - същите инструменти, същото обкражение. Само за пример ще ти кажа, че в моя случай не се налага добавянето на каквото и да било в системна променлива на обкръжението - нито в пътя, нито някъде другаде. Нямам нужда и от make - използвал вътрешния builder на CDT-то.

Конфигурационният файл на OpenOCD например си се избира като конфигурация за външен tool в еклипса - на падащото меню имаш възможните конфирурации, и стига да има съответния tool нещата си работят.

На колко комерсиални IDE-та си виждал да има инструкция как да си настроиш инструментите слагайки ги на системния път?




Е, лесно, лесно - колко да е лесно - дали не е по-лесно да избера от list box едната опция с коментар към нея, или да пиша в текстовия файл?
С подходящия toolchain плъгин всичко се свежда до чекбоксчета, диалози за избор на файл или папка, лист боксове и т.н. Определено е много по-удобно от писането по текстови фаилове.

На еклипса сеттингс и проектните файлове също са текстови, и са версионно контролирани.



Чукчето и бъгчето бачкат по същия начин и на managed проектите - build конфигурациите са си там.

Разбира се че с makefile можеш да свършиш същата работа, дори само с текстов редактор. Въпрос на подход и познаване на инструментариума.

Като краен резултат има една стандартизирана инсталация на еклипса, и "простия" девелопер го инсталира и чекаутва проекта. Както и става в нормални (комерсиални) IDE-та. И е лесно, не му се налага да разбира от makefile-ове за да си добави своите произведения в проекта. Има си десен бутон, GUI за конфигурирането и се радва.

Миро е прав за make файловете. Отначало и аз ползвах менажирани проекти и прочие дивотии. Да ама с мейк файлове, напрактика мога да компилирам даже и въобще да нямам еклипс. А това аз често го правя, когато трябва да променя нещо малко в сорса. Особенно ако промяната трябва да се направи от друг човек на отдалечен компютър (нещо като патчване). Да му обяснявам как да инсталира еклипс, да го настройва и прочие.... брррр... Трябва му само gcc, един текстов редактор и толкова. Редактира, пише маке и пуска програматора. Толкоз.
По този начин проекта ти става абсолютно независим от IDE средата. Което си е огромен плюс според мен. Щото ако този на който даваш сорса е любител на IAR например, ще почнат едни въпроси.....

А това, че на еклипса няма как да се прехвърлят настройките от един проект в друг си е голямо говно. Не, че е нерешим проблем, ама е дразнещо всеки път да го конфигурирам, вярно е.

Така, че Еклипса е хубаво нещо, ама по добре човек да пази дистанция и да го ползва, без да е зависим от него.

Въпрос на гледна точка - ако го даваш на любител на еклипс, ще те пита що е то make. Казваш само gcc му трябва - не баш, трябва си и make, и всичко по линията. Дали слага gcc или слага еклипс с gcc - разликата е в размера на архива...

Не познавам толкова дълбоко еклипса и определено не му ползвам и малка част от възможностите (като например свързаните проекти), но не виждам предимство в това да държа една и съща информация на две места - в еклипския проект и в мейк файла. Ако не се ползва еклипс, ок.

Винаги има предимства да не се обвързваш с конкретен инструмент - въпрос на преценка кога тази независимост си заслужава.

Отделно другата посока е възможна и лесна - от managed проект еклипса може да генерира make файл, които да дадеш на клиента да си билдва. Отделно не виждам защо в цитирания случай ще даваш целия проект - правиш библиотека с твоя код, и той да я ползва добавяйки своите сорсове. Така и know-how to остава при теб.

Ще поживеем и ще видим кой е правилния метод за нас.

Колкото и да живееш - няма да видиш кое е по - добро. Разни хора - разни идеали.

Цецо, не ставай смешен. Менажираните проекти като резултат правят също мейк файлове, които можеш да използваш по същия начин както и ръчно направените - без Eclipse ако е само за едното билдване.

gicho, аз правя така. Взимам проекта, чиито настройки искам да използвам. Копирам цялата папка някъде, сменям и името с името на новия проект. След това редактирам ръчно .cproject и .project файловете с Wordpad. С Find/Replace заменям навсякъде стринга на старото име на проекта с новото име. След това прехвърлям цялата папка на този проект в workspace-a. Отварям workspace-a с Ecplipse после File->Import. В отварящия се прозорец за Import избирам "Existing Projects into Workspace". Чукаш на "Next" в прозореца на следващата стъпка намираш директорията на workspace-a(чукваш на "Browse" после "ОК" по подразбиране ти отваря пътя към отворения в момента workspase). Там ще ти се появи новия проект чиято папка си вкарал ръчно в директорията на workspace-a...
Сори за подробните обяснения стъпка по стъпка.
Ей така си заквасвам нов проект.
После изтриваш всички файлове и добавяш новите файлове към проекта и готово.

Разбира се всеки избира да работи както му е удобно. Колегата ми сам си пише мейк файловете и почти не пипва мишката за което му отдавам респект. За мен по-удобен е графичния интерфейс.

Много си далеко от истината... За прости hello world проекти може и да ползваш managed, но за по-сложни неща просто забрави. Има една книжка "managing projects with GNU make" та там автора даваше примери за проекти в които само мейкфайловете са над 100 000 реда. Аз разбира се не бачкам с чак толкова големи проекти, но постоянно изкачат разни дивотии. Примерно последно ми се наложи да слагам lwIP стека в библиотека. Самият стек си има някаква организация на сорс и инклуд директориите, която е ОК стига да го компилираш така както е. Но когато го компилираш с цел библеотека вече не е достатъчно просто да се компилира до а-файл. Трябва да се експортират и хедърите.
Принципно една от причините да се прави библиотека може да е да се скрият сорс файловете, затова експортните хедъри се копират в изходната директория при либ-файла. В случая обаче с lwIP-то някои хедъри ползват други и т.н. Естествено всички трябва да се експортират, но не просто да се копират, ами трябва да се запази и определена структура, защо те ползват пътища, т.е. неща от типа #include "folder/header.h". Проблемът в случая е, че трябва да се изчисли каква част от пътя да се запази и как. Защото като компилираш самото lwIP имаш няколко include директории и пътищата са спрямо тях, а след като стане библиотека вече е една и е друга директория...
Разбира се може и ръчно да се копират, но е тъпо щото след 5-6 месеца ще съм забравил кое къде се копира. Бих могъл да напиша BAT файл или py скрипт, ама пак е кофти щото утре ще променят нещо в lwIP-то и аз като синхронизирам ще се омаже... Предпочитам да го направя с мейк и да става автоматично, така че да не се налага да помня или да променям в бъдеще нещо...
Сега ще кажеш ама защо тия гадове от lwIP не са го направили. Ами може би не им се е налагало да правят библиотеки.

Всъщност целият проблем е, че всеки ползва различна организация. Няма някакъв стандарт. Ти си правиш някаква организация за твоя проект, но ако ползваш чужд ОС, TCP/IP стек, файлова системка или нещо друго ще се сблъскаш с различни организации. Просто така стоят нещата.... Когато ползваш сосрсове с различни организации се налага да правиш врътки...

Слава Богу мейк позволява всякакви врътки, защото си е като скрипт/език за програмиране. Докато managed системите са по-скоро като тия visual инструменти дето не пишеш код, ами цъкаш с мишката... Не може да се сравняват! Програмирането си е програмиране... То ако можеше да се замества с wizard-и сигурно първо щяха да заместят C/C++ програмирането

Разбира се, аз гледам да не се увличам много-много в сложни мейк програмирания.... И в повечето случаи правя нещата по начин близък до managed нещата. Но не бих казал, че това е "допотопен" начин или има някакви недостатъци. Не изисква повече време или усилия. Много по-удобно е за синхронизиране! По-удобно е за редактиране (search/replace).

С други думи дори без врътките пак не бих заменил make с automake! А пък като опре до врътки (а то почти винаги опира) вече няма избор

Това е някакво решение за теб самия. Сигурно ти върши работа... ОК но е ГРОЗНА практика!

Той и Гичо има същите очаквания:


В реалния свят не може да очакваш от клиентите да имат инсталиран един и същ тулчейн, с една съща версия, на едно и също място. Проектите също да са на едно и също място...

В моя случай *няма* нищо общо! Едни работят под лайнукс, други с боза... Всеки ползва различен тулчейн, различен jtag, различни таргет процесори, даже проектите се ползват за съвсем различни продукти. Само *част* от сорс кодът е общ!

Самият еклипс също е много различен, т.е. забрави да редактираш .cproject! Не става! Аз в някои проекти имам инсталирани плъгини за vhdl, PHP, XML и т.н. Това прави моите файлове различни, дори и пътищата да бяха еднакви, а те не са и не могат да бъдат еднакви...


Както и да е... ако искате си ползвайте automake. Аз не мога да ви спра, но ви казвам че не е добра практика... Утре ще ви се наложи да направите нещо по-различно и ще се озъбите

Да уточня нещо, дето май не се разбра. Мигрирам съществуващи проекти, които си имат SVN repository, където са сорсовете и проектните файлове на старото IDE.
Сега искам да добавя възможност същия сорс да се работи през Еклипс - т.е. добавям новите еклипски проектни файлове към съществуващата структура на репозиторито.

Не проследих изцяло стъпките на Zdrav, не знам дали ще сработят понеже проекта е на SVN, а не локален (file system). Отделно самите проекти ползват външни репозиторита за разни компоненти (които са споделени между повече проекти).
Докато рових из нета видях подобен проблем описан, и човека говореше точна за тия числа около разните ресурси:

[url]<cconfiguration id="org.eclipse.cdt.cross.arm.gnu.yagarto.windows.elf.debug.1801340995">[/url]

Разбира се!!! Това е решение за мен самия. Мисля че в един виртуален форум има място за споделяне и на такива решения. Все пак нямам претенциите да налагам практика, нито идеология. Опазил ме Бог.

Zdrav ти обяснява как да синхронизираш еклипските .cproject и .project ...

Аз ти казвам да не го правиш, защото в общия случай това са локални и индивидуални файлове. Така или иначе досега в репозиторито нямаш еклипски файлове нали? Е, не ти и трябва да имаш... Слагаш си ги в .svnignore и то няма да ги синхронизира. Самият .svnignore може да го качиш, така че някои като чекоутне и след това си направи проект на еклипс няма по погрешка да качи неговите лични файлове.

Знаеш предполагам, че нито аз нито Цецо сме искали да те засегнем... Аз писах по-горе, че няма перфектен начин как да си организираме нещата. Съответно всеки може да предпочита един или друг подход.

Но все пак аз си позволявам (извинявай за което) да препоръчвам определена практика просто защото съм инвестирал много време в разглеждане на най-различни решения и съм се сблъсквал с предимствата и недостатъците им. Специално вариантът с managed меко казано не е добър. Но не го казвам за да спорим или да се обиждаме. Казвам го защото бих могъл да помогна на всеки да навлезе и в "другия начин".