Eclipse + CDT + version control

C/C++

Udv,

Elkezdtem kicsit "szorakozni" Eclipse Europa-val (C/C++ pluginnel). Felraktam a subclipse nevu plugint ami elvileg svn-nel torteno kommunikaciot oldana meg. Olyat talaltam is hogy tud importaqlni egy projectet svn-bol, viszont halvany lila dunsztom sincs hogyan tudok egy uj workspace-t betenni svn-be. Igazabol ez az egesz integralt miskulencia nem is lenne annyira fontos, ha tudnam mik azok a fajlok amiket be kell toljak svn-be hogy kesobb a workspace (projectekkel egyutt) onnan barhova visszaallithato legyen.

Elore is kosz az infot

  • 1457 megtekintés

( ssikiss | 2007. 09. 20., cs – 11:29 )

Szerintem az a gond, hogy a workspace-hez tartozó fájlokat nem tudod közvetlenül eclipse-ből verziókezelni, meg sem jelennek a keretrendszerben, a verziókövetés pedig projektalapú.
A workspace-ben amúgy sincs igazán lényeges adat, úgyhogy inkább lehetne egy repóba rakni az összes egy workspace alatt használt projektedet. Egy visszaállításnál mondjuk ezzel annyi munka lenne, hogy egy checkout után minden projektet egyesével kellene (vissza) importálni egy újonnan létrehozott workspace-be.

A workspace-ben amúgy sincs igazán lényeges adat

Hat nem ismerem meg nagyon az eclipse-et, viszont picipuha fejlesztorendszerrel termeszetes felallas egy nagyobb project eseten, hogy az alkalmazasok altal kozosen hasznalt kodokat libraryba rakja az ember, es a workspace-ben (solutionben) bent vannak a hasznalt libek es az alkalmazas is, az alkalmazas pedig "fugg" a libeken, igy ha a libekben valtoztatsz valamit, a build folyamat az alkalmazas leforditasa elott a modosult libeket le fogja forditani. Nem tudom ez lehetseges-e eclipse eseten, de nagyon szomoru lennek ha nem lenne az.

Az eclipse-ben ilyen nincsen, az csak egy keretrendszer. A c/c++ spec funkciókat a cdt csinálja, ami jelenleg beépítetten make file készítésre és használatra van felkészítve. Ezt a részét én nem használtam (mert cmake-t használok, ami intézi maga az egyes fordítási egységek függőségeinek kezelését).

Viszont, megadható a projektek közötti egymásra hívatkozás (project references), ami szerintem azt csinálja, amit te szeretnél - úgyhogy mégis csak van benne ilyen :). Szerk: + build order - az is jól jöhet :).

Jó howto-t nem tudok, csak nagyon alap cikkek vannak róla. Én nagyobb projektek fájlait nézegettem példának és inspirációnak. Kis projektekre (define kis projekt!) is teljesen jól használható, és az autoconf+automake páros használatáról áltam át rá. Nekem emészthetőbb volt a nyelve, gyors, és korrekt a függőségkezelése is. A legvonzóbb tulajdonsága számomra az volt, hogy a saját leírófájlaiból tud generálni linux és windows fordítókra is make ill. projektfájlokat (persze azért nem old meg mindent alapból).

#ifndef KIS_PROJEKT
#define KIS_PROJEKT "
Mivel nem értek annyira a C/C++ dolgokhoz, de időnként tanulgatom/szükségem van pár dologra amit C-be kell megírni (pár C/CPP meg H fájl, amik egy .so-t meg egy sima végrehajthatót termelnek ki), ezért muszály voltam eddig auto* rendszert használni. Viszont nagyon bonyi, nincs egy egységes leírás, hogy akkor most ezek és ezek az m4 makrók vannak ledefiniálva by default, meg ilyenek. Úgy kellett mindent összevadászni a neten különböző projetkeből, hogy nézzen már ki vhogy a dolog.
"
#endif

Én tudok kódok alapján is tanulni ha muszály, de egy referenciakönyv sokat tud dobni a munkasebességen.

Pár forrásfájlos projektre szerintem felesleges az ilyesmi, oda sima makefile-t kell írni. (bár mostmár mindenhova inkább cmake fájlt írok)

Egyébként az auto* rendszer doksija info fájlokban van, az egész használható szerintem.

A cmake honlapon van a Documentation alatt egy parancsref és a wikiben még további hasznos dolgok (useful variables, cmake+eclipse, eclipse plugin, tutorial-ok stb).

Na most én eleve amit az info megnyit azt úgy nem szeretem. Még mindig nem jöttem rá, hogy lehet normálisan navigálni benne, és eleve valahogy nehézkes az egész.
A CMake honlapját én is most néztem, szerintem érdemes lenne megtanulni, egész használhatónak tűnik.

Persze, pár forrásos projetkre nem csinál az ember - ha már megtanulta kezelni. Amíg nem ismerem, addig egyelőre csak pár forrásos projekten van merszem tesztelni, hogy hogyan műx a dolog.

Eclipse alatt az alap felállás az, hogy projekteket teszel repóba és csekkolsz ki. Azaz az egész workspace nem egyetlen SVN könyvtár, hanem sok.

Igy a projekteket egyesével kell kicsekkolni, és ha csinálsz egy újat, akkor egyesével kell "betenni" (sajnos nem tudom mi a jó szó, talán import?) a repóba.
A kicsekkolásban segíthet, hogy lehet csinálni gyűjtőprojektet, amiben az SVN-es projektekre hivatkozol, így azokat egyben ki tudja szedni.

Az egymásra épülést be lehet jelölgetni a projektek között. CDT-val nem sokat foglalkoztam, mikor utoljára néztem elég fapadosnak tűnt... Makefile-okkal dolgozik és a command line eszközöket hívogatja. Vagy teljes mértékben kezeli a Makefile-okat, vagy egyáltalán nem. Amit ő kezel, abba alig sikerült belenyúlni kézzel(bár talán nem is kell). Odáig sikerült vele azért eljutnom, hogy windowson(mingw-vel) és linuxon is vígan forgó alkalmazást sikerült vele csinálni, tehát használható.
Persze az Eclipse JDT-hez képest minden IDE fapadosnak tűnt nekem eddig :-)

Amúgy mit csinálsz vele?

Az improt az a workspace-be importal a repobol. Meg nem talaltam lehetoseget a project "exportjara" azaz a repoba rakasara eclypse+CDT+subclipse alatt. Mondjuk ezt viszonylag egyszeruen meg tudom tenni kezzel is.

Odáig sikerült vele azért eljutnom, hogy windowson(mingw-vel) és linuxon is vígan forgó alkalmazást sikerült vele csinálni, tehát használható.

Azert ez meg mindig a hobby felhasznalas kategoria szerintem. Ahoinnan en ra mernem vagni hogy hasznalhato, az minimum az a pont hogy a workspace-en belul van egy vagy tobb library, amit az alkalmazas kesobb hasznalni (a debugger pedig debuggolni is) tud. Ma azert mar eleg ritka za "egyedulallo" alkalmazas, az egymassal kapcsolatban dolgozo tobbretegu alkalmazasok pedig normalis design eseten a kozos reszeket sajat library-ba teszik ki es kozosen hasznaljak.

Amúgy mit csinálsz vele?

Mint a temainditoban irtam, ismerkedek. Szeretnem kivaltani vele az M$ fele visual studiot, amit ha legalis akarok maradni max 180-napig hasznalhatok (180 napos trial toltheto le a picipuhatol), na meg picipuhaOS-en kivul brahol mashol eselytelen futtatni. A mai vasakon az eclipse java miatti teljesitmenyhatranya annyira mar nem problema, viszont nem nagyon talaltam meg mas hasznalhato c/c++ multiplatform IDE-t. (ultimateC++ nevetseges, anjuta, kdevelop, motor meg posix-only. Esetleg a netbeans IDE c++-os verzioja erhet meg meg egy kort, de azzal meg nem volt idom szorakozni)
Itt a cegnel MSVS a kornyezet, igy ha lehet sajat hobbyprojecteimhez is valami hasonlo filozofiaju ide-t keresnek. Az eclipse egyenlore meg eleg jol vizsgazik, az svn problema tekintheto megoldottnak azzal a kis engedmennyel hogy nem a teljes workspace-t hanem csak a projecteket tudom tarolni benne. Ami most izgat, az az hogy ha van egy library meg egy alkalmazas a workspace-ben, hogyan tudom megmoindani az alkalmazasnak hogy egyreszt a library-hoz linkeljen, masreszt hogy o a liben "fugg" azaz ha van rebuildelni valo a libben, az alkalmazas buildje elott azt tegye is meg.

Futottam. Kb annyit er mint egy kiherelt tenyeszbika. Ha azt mar nem is szamoljuk hogy valodi munkara (amiert adott esetben fizet neked valaki) a licensze miatt nem hasznalhato, ilyen aprosagokban akadtam el ,mint pl hogy nem tudtam wim32 projectet letrehozni benne. Kb itt fel is adtam. Akkor mar inkabb szopok az eclipse-szel, az legalabb free.

Több könyvtárba természetesen szétszedheted az alkalmazást Eclipse-CDT alatt is. Hogy pontosan hogy azt viszont ne tőlem kérdezd :-).

Debuggolás is működött nekem, megint csak ne kérdezd, hogy hogyan.

Amúgy ha a termék platformfüggősége a bajod, akkor arra a megoldás nem az IDE választása, hanem az "ügyes" független könyvtár válogatás. Valaki pl javasolta itt az SDL-t TCP-re és thread kezelésre. GUI-ra van GTK vagy WxWidgets. Nekem bevált, frankó Linux-Windows multiplatform kódot csináltam vele. Windowson fejlesztettem és utólag írtam hozzá Linuxra makefile-t, meg persze kicsit hekkeltem egy-két apró nem-hordozható cuccon. Szerintem egész jól járható út volt ez.

SVN-be betenni a projektet úgy kell, hogy a projekten jobbklikk, menüben team-share... Feljön varázsló, ahol a feladminisztrált repo-k közül választasz, elnevezed a repo-beli könyvtárat, majd usgyi. Pont úgy megy a varázsló, mint CVS-sel.

Azért kérdeztem, hogy mire kell, hogy esetleg nem Javára lenne-e inkább szükséged :-)? Persze ez off, de mégis.

( Polesz v | 2007. 09. 22., szo – 20:16 )

Subclipse helyett használd inkább a Subversive plugint. Sokkal jobb.

--
A nyúl egy igazi jellem. Ott ül a fűben, de akkor sem szívja!