[Eclipse/CDT] Projectstructuur: onmogelijk?

[Verwijderd]

Wanneer ik MSVC (willekeurige moderne versie) gebruik, dan is er de mogelijkheid om een workspace aan te maken met daarin meerdere projecten, welke allemaal apart te bouwen zijn en een serie executables en/of bibliotheken oplevert. Deze projecten kunnen mbv mappen ingedeeld worden zodat er een mooie directorystructuur ontstaat.

Dit wil ik ook met Eclipse en de CDT plugin, maar tot nu toe kom ik niet verder dan dit:

XML:

<workspace>

  <project:hoofdprogramma>
    <map:source/>
    <map:include/>
  </project:hoofdprogramma>

  <project:bibliotheek1>
    <map:source/>
    <map:include/>
  </project:bibliotheek1>

  <project:bibliotheek2>
    <map:source/>
    <map:include/>
  </project:bibliotheek2>

  <project:plugin1>
    <map:source/>
    <map:include/>
  </project:plugin1>

  <project:plugin[n]>
    <map:source/>
    <map:include/>
  </project:plugin[n]>

  <...>

</workspace>

Dit is natuurlijk "pseudo-xml".

Alle projecten hangen dus op het eerste niveau onder de workspace. Maar dat is niet wat ik wil. Wat ik wel heel graag wil is dit, of iets vergelijkbaars:

XML:

<workspace>

  <project:hoofdprogramma>
    <map:source/>
    <map:include/>
  </project:hoofdprogramma>

  <folder:statische_bibliotheken>

    <project:bibliotheek1>
      <map:source/>
      <map:include/>
    </project:bibliotheek1>

    <project:bibliotheek2>
      <map:source/>
      <map:include/>
    </project:bibliotheek2>

  </folder:statische_bibliotheken>

  <folder:plugins>

    <project:plugin[n]>
      <map:source/>
      <map:include/>
    </project:plugin[n]>

    <...>

  </folder:plugins>

</workspace>

Nu is het in het eerste voorbeeld niet zo heel erg om alles op het eerste knooppunt van de hiërarchie te houden, maar in de echte situatie (dit is natuurlijk maar een simpel voorbeeld) zijn er minstens dertig plugins (dll's) die er nog eens extra bijkomen, waardoor ik het overzicht helemaal kwijtraak.

De plugins wil ik ook graag indelen in mappen omdat er nog meer plugins bij zullen komen.

Ik zou kunnen overstappen op zelfgeschreven makefiles, maar dat doe ik liever niet omdat:
• ik het veel te belangrijk vind om de extra opties te behouden van de managed make builder
• het hele managed/standard make-spul in CDT 4.0 overhoop is gegooid

Wat is nou eigenlijk het probleem? Simpel: er kunnen geen mappen worden aangemaakt onder de workspace. Eclipse wil daar alleen projecten in hebben.

Is er misschien nog een andere mogelijkheid om te doen wat ik wil zoals in het tweede voorbeeld? Of ben ik echt eeuwig verdoemd tot het plaatsen van alle projecten in een lange oneindige workspace zonder enige vorm van structuur waardoor mijn programmeerleven een dikke zonsverduistering over zich heen zal krijgen omdat ik door de projecten de code niet meer zie...

[NetForce1]

working sets are your friend Als je niet altijd alle plugins en libraries open hebt staan, wat me zeer waarschijnlijk lijkt, kun je het opdelen in verschillende working sets. Een working set is een setje projecten, je kunt een of meerdere working sets zichtbaar maken (iig in de java package explorer). Verder kun je ook nog overwegen om verschillende source folders te maken in je project, maar dat lijkt me niet echt fantastisch.

[Verwijderd]

Working sets heb ik geprobeerd maar zijn helaas absoluut niet m'n vrienden. Het is in mijn ogen meer een manier om de tekortkomingen van de project explorer mee te maskeren.

Naast dat ik het niet handig vind om mee te werken lost het ook mijn probleem helemaal niet op. Ik wil namelijk ook buiten Eclipse om nog een beetje overzicht kunnen hebben. Wanneer ik een workspacemap voor Eclipse volgooi met veertig verschillende projecten (waarvan dus die dertig plugindingen), dan heb ik in een standaard Explorer (die van Windows) een rommeltje waar ik geen working sets in kan gebruiken, aangezien Explorer die niet heeft.

Ik heb ook nog geprobeerd om verschillende workspaces te maken en zo op die manier de beperking uit m'n eerste post te omzeilen, maar ook dat is een paardenmiddel omdat je dan niet simpel even snel in een ander project kan kijken ivm het switchen tussen verschillende workspaces, wat toch even duurt omdat de hele omgeving dan opnieuw wordt opgestart en je dan niet tegelijkertijd in de bovenliggende projecten kan komen. Dat is dus ook geen optie.

De verschillende source folders had ik ook al overwogen, alleen voor zover ik begrijp is het ook daarmee niet mogelijk om het probleem te omzeilen omdat je nog steeds met de beperking van die projecten zit. Ik kan al m'n code wel in verschillende source folders gooien, maar hoe maak ik daar dan verschillende libraries en executables mee? Dat kan voor zover ik kan zien niet omdat het nog steeds binnen een project moet hangen (en daarmee maar een enkele vorm van output heeft: een executable of een library, maar niet meer tegelijk).

[NetForce1]

De verschillende source folders had ik ook al overwogen, alleen voor zover ik begrijp is het ook daarmee niet mogelijk om het probleem te omzeilen omdat je nog steeds met de beperking van die projecten zit. Ik kan al m'n code wel in verschillende source folders gooien, maar hoe maak ik daar dan verschillende libraries en executables mee? Dat kan voor zover ik kan zien niet omdat het nog steeds binnen een project moet hangen (en daarmee maar een enkele vorm van output heeft: een executable of een library, maar niet meer tegelijk).

Voor zover ik weet kan dat met de java plugin wel, je kunt dan een export descriptor aanmaken die je op kunt slaan in je project. Zo kun je voor iedere library/executable een andere descriptor maken. En anders kun je ook nog met build scripts werken. Wij doen hier alles met ant, ik vermoed dat CDT ook wel een fatsoenlijke make integration heeft.

[Verwijderd]

Nee, met de Make builders van CDT (ook niet die in 4.0) kan dat voor zover ik kan zien ook niet

Ik kan wel apart bestanden gaan zitten includen en excluden en zo toch alles krijgen zoals ik wil, maar dat is het ook niet echt omdat je er snel fouten mee maakt, het configureren ervan langzaam is (vinkjes neerzetten in property-dialogen..) en er dan alsnog aparte projecten in de root/workspace moeten staan.

Overstappen op een alternatief systeem is niet echt een optie omdat voor de meeste systemen geen goede integratie met Eclipse beschikbaar is en de alternatieven zelf ook verschillende problemen hebben waardoor m'n programmeerleven een stuk moeilijker wordt gemaakt.

Ik noem bijvoorbeeld maar de verschrikkelijk lange buildtijden van CMake, wanneer dat gebruikt wordt onder Windows en een FAT32 partitie.

Nouja, bedankt voor het meedenken iig
Ik denk dat er voorlopig even niets anders op zit dan het op z'n Java's oid te gaan doen (alles prefixen dus).

[Creepy]

En veel te laat maar bij deze alsnog: move naar Development Tools & Environments. Zie ook Waar hoort mijn topic?

[Verwijderd]

Oeps, sorry

Was me nog niet opgevallen dat daar ook een apart forum voor was