(Teil)Projekte verbinden



  • Hallo,
    weiß jemand wie ich meine Qt-(Teil)projekte am Ende zu einem einzigen
    Projekt "verbinden" kann ??
    In meinem Workspace habe ich 10 Projekte angelegt, von denen jedes
    eine bestimmte Teilaufgabe des Gesamtprojektes erfüllt.
    Gesamtprojekt ist z.B. das Konvertieren von Multimedia-Dateien ... dann
    habe ich in meinem Workspace ein Projekt, das nur die GUI-Funktionalität
    enthält, ein zweites Projekt, dass nur Berechnungen durchführt, ein
    drittes Projekt, dass die MM-Dateien zum Ende konvertiert, ein viertes
    Projekt, dass ...
    Jedes (Teil)projekt hat seine eigene main()-Methode, damit ich sie
    unabhängig von den anderen Projekten entwickeln und testen konnte.
    (bin mir aber nicht sicher ob das unbedingt nötig war 🙄 )
    Entweder, ich erstelle ein neues "Gesamtprojekt" im Workspace, und greife
    irgendwie auf die Teilprojekte zu ??? ... oder, ich erstelle einen
    neuen Workspace, und darin ein neues Gesamtprojekt, in welches ich
    dann die Teilprojekte einźeln importiere ???
    Oder, ich mache es ganz anders 🙂 ... aber wie ???



  • Wenn du jede main()-Methode in einer eigenen Source-Datei hast, dann baue dir einfach ein neues Projekt mit einer weiteren main()-Methode und binde alle benötigten Source-Dateien (außer eben den main-Dateien der anderen Projekte) ein.



  • Es wird wohl nur irgendwie so gehen ...
    Leider ist das neue Projekt auf der gleichen Ebene wie die existierenden
    Projekte ... wie soll ich da auf die Ĥeader/Source-Dateien der
    anderen Projekte zugreifen ? Die müsste ich dann wohl mit
    einer absoluten Pfadangabe einbinden !?!?



  • Es müsste doch auch klappen, wenn du im jetzigen Projektordner symlinks auf die anderen Header/Sourcen erstellst und dann die Dateinamen der symlinks einbindest? Damit könntest du zumindest absolute Dateipfade vermeiden.



  • @frogi001

    denen jedes eine bestimmte Teilaufgabe des Gesamtprojektes erfüllt.

    An Sich ne Gute Idee.

    Wie man sowas verwaltet, haengt natürlich von paar punkten ab:

    - Sind deine Teilprojecte autark? Koennen und sollen die ausserhalb des gesamtprojekts vwerwendet werden?
    - was sind das für Project-typen? Im ersten moment liest sich das, als waeren das alles eigenstaendige Executiables? Oder sinds doch Bibliotheken (warum haben die dann nen main? oder haben nur die tests die main?)
    - Wie wird der SourceCode verwaltet/gesichert? Versionsverwaltung(cvs,svn,git... ) geplant?

    Leider ist das neue Projekt auf der gleichen Ebene wie die existierenden
    Projekte ... wie soll ich da auf die Ĥeader/Source-Dateien der
    anderen Projekte zugreifen ?

    Du kannst mit "..\" bei den meisten system auch aus deinem Projectverzeichnis raus und in andere wieder rein ...
    Prinzipiell ists aber ne schlechte Idee, Source Dateien aus anderen eigenstaendigen Projekten in dein eigenes Projekt einzufügen ...

    Besser: gemeinsam von mehreren Projekten verwendeten Code in ein eigenstaendiges Project / Bibliothek auslagern !!!

    mit reinen IDE's ist man oft sehr limientiert und unflexibel, was so automatismen und einlinken anderer Bibs betrifft.
    mehr flexibilitaet bieten da build-generatoren, z.b. cmake, qmake da kann man schon ne menge mit machen ....

    Versionsverwaltungen stellen manchmal auch notwendige technicken zur verfügung. subversion z.b. die externals.

    Ciao ...



  • Hallo,

    Sind deine Teilprojecte autark?

    Jedes einzelne (Teilprojekt) kann ohne irgendwelche Abhängigkeiten
    zu anderen Projekten compiliert und ausgeführt werden - erzeugt
    also eine eigene ausführbare Datei.

    Vielleicht sollte ich noch erwähnen, dass ich das Gesamtprojekt
    für die BS LINUX und WIN entwickle (getestet unter Slackware 13.37,
    Ubuntu 12.04, WIN XP und WIN Vista)

    Koennen und sollen die ausserhalb des gesamtprojekts vwerwendet werden?

    In erster Linie werden die Teile nur innerhalb des aktuellen Projektes
    benutzt -- habe aber schon darauf geachtet, dass ich sie ohne
    große "Umschreibaktionen" auch anderweitig verwenden
    kann ... wahrscheinlich !?!? :p

    was sind das für Project-typen?

    Ich benutze das QT-Plugin (nennt man das so ??) für eclipse cdt.
    Ein Projekt ist ein QtGui-Projekt, und die anderen sind
    alle Qt-Konsolen-Projekte. Das Gui-Projekt hat als einzige
    Aufgabe die Grafische Benutzeroberfläche zur Verfügung zu stellen ...
    enthält also keinerlei "Intelligenz" 🙂
    Aus diesem Gui-Projekt (genauer gesagt aus der
    erzeugten grafischen Oberläche) heraus sollen nun die anderen
    Projekte angesprochen (aufgerufen) werden, die dann die
    eigentliche Arbeit erledigen (Dateien sortieren, Dateien
    konvertieren, Videos schneiden, Audio-Dateien zusammenfügen u.s.w).

    Im ersten moment liest sich das, als waeren das alles eigenstaendige Executiables?

    Sie sind es 🙂 ... wobei mir schon auf halbem Wege die
    Sache etwas "seltsam" vorgekommen ist !!

    Oder sinds doch Bibliotheken (warum haben die dann nen main? oder haben nur die tests die main?

    Das Gui-Projekt ist noch nicht durchgetestet - muss noch überlegen
    wie ich das mache. Die anderen "Nicht-Gui-Projekte" habe ich mit
    CppUnit "getestet" ... wenn man das "testen" nennen kann !! 🙄
    Diese Unit-Tests sind in meinen Augen nicht das
    richtige Mittel um etwas größeres Programm (im Gesamten)
    zu testen.
    Die main()-Methoden sind nur deswegen vorhanden, um während der
    Entwicklung der Klassen diese auch mal "durchlaufen" zu lassen.
    Wenn das (Teil)projekt fertig ist, dann brauche ich die main()-Methoden
    nicht mehr.

    Wie wird der SourceCode verwaltet/gesichert? Versionsverwaltung(cvs,svn,git... ) geplant?

    Bei früheren Projekten habe ich schon svn als Versinsverwaltungstool
    benutzt. Wenn ich allerdings alleine an einem Projekt arbeite, dann
    setze ich es normalerweise nicht ein. Die Sicherung des Quellcodes
    läuft so mit der normalen Datensicherung mit.

    Du kannst mit "..\" bei den meisten system auch aus deinem Projectverzeichnis raus und in andere wieder rein ...
    Prinzipiell ists aber ne schlechte Idee, Source Dateien aus anderen eigenstaendigen Projekten in dein eigenes Projekt einzufügen ...

    Das habe ich auch probiert ... ist aber nicht zufriedenstellend 😞 ... ich
    kann natürlich ohne Probleme die Header-Dateien in mein
    Projekt einbinden ... aber die .cpp-Dateien muss ich dann irgendwie
    anders in mein Makefile bekommen ...

    mit reinen IDE's ist man oft sehr limientiert und unflexibel, was so automatismen und einlinken anderer Bibs betrifft.
    mehr flexibilitaet bieten da build-generatoren, z.b. cmake, qmake da kann man schon ne menge mit machen ....

    Genau !!! ... "hier liegt der Hase begraben !" 😉
    Ich habe nun mit dem Qt-Creator, Netbeans und Eclipse
    gearbeitet ... und jedes dieser Teile hat irgendwo seine
    Limitierungen !!! (natürlich auch ein paar Vorteile)
    Mir ist schon klar, dass ich mit den "alten Tools" wie make, cvs und gdb
    flexibler bin als mit den "neuen" IDEs 😃 (aber auch nur,
    wenn man weiß wie man mit diesen Tools umgeht !!) ... aber
    irgendwann bekommt auch ein anderer Entwickler dein Projekt
    in die Hand, und du musst nur noch erzählen, dass du auf der Kommandozeile
    linkst und compilierst ... cvs als Versionsverwaltung benutzt, und
    zum Debuggen benutzt du den gdb auf der Kommandozeile ... da kannst du
    gleich einen Termin zur "Krisensitzung" vereinbaren 😃
    Auf der anderen Seite klicke ich nun schon drei Tage mehr oder
    weniger sinnvoll in eclipse rum, ohne eine akzeptable Lösung
    gefunden zu haben ... in dieser Zeit hätte ich mich auch wieder
    in qmake, make und gdb einarbeiten können ... 😕
    was ich jetzt aber auch tun werde !! 🙂



  • aber irgendwann bekommt auch ein anderer Entwickler dein Projekt
    in die Hand, und du musst nur noch erzählen, dass du auf der Kommandozeile
    linkst und compilierst ... cvs als Versionsverwaltung benutzt, und
    zum Debuggen benutzt du den gdb auf der Kommandozeile ... da kannst du
    gleich einen Termin zur "Krisensitzung" vereinbaren

    Wer dein Project übersetzen/bauen muss, wird sich mit deinen Tools auseinander setzen muessen, wohl oder uebel ^^
    Glaub mir es gibt Projecte .... da iss ne Verwendung von qmake das wenigste Problem.

    Beispiel: Boost. Um booost selber zu kompilieren, musst deren eigenes Build-Tool verwenden !!! und das ist was, was wahrscheinlich sonst keiner einsetzt ^^

    Die frage ist, ob du jeden zwingen willst, dein Project selber zu builden.
    Wenn du executables auslieferst, wahrscheinlich eher nicht, oder ?

    Wenn ich das richtig verstehe ... ist deine GUI nen executable, deine Tools sind auch executables, und die schnittstelle zwischen GUI und tool sind die commando Options sowie cout ??? RIchtig ?

    Bleibt die Frage dann, warun Du deine projecte miteinander verheiraten willst ??? Sie sind doch schoen und maximal voneinander getrennt ... das ist doch eher nen vorteil als wie nen nachteil ?

    du verwendest doch nicht die gleichen sourcen (cpp dateien) in mehreren executables (Projecten) ?

    Ciao ....



  • Wenn die ganze Sache fertig ist, dann jeder den Quellcode haben. Aber
    nicht jeder Anwender kann sich ein Programmcode aus den Quelltexten
    selber "zusammenbauen". Die "normalen" Anwender bekommen eine
    ausführbare Datei, worauf sie einen Doppelklick machen, und das Programm
    startet.

    Beispiel: Boost. Um booost selber zu kompilieren, musst deren eigenes Build-Tool verwenden !!! und das ist was, was wahrscheinlich sonst keiner einsetzt ^^

    😃 ... ich verwende Boost 😃 ... nutze aber nur die Möglichkeiten
    zum Filesystem (Rechte auslesen, Ordner einlesen u.s.w) ... habe zu spät
    bemerkt, dass es mit Qt auch ganz gut geht. Unter Windows war es
    nicht ganz so toll Boost zu "benutzen" 🙄
    Unter http://edv-hable.de/mmk/ ist ein Entwurf der GUI
    für Linux und Windows zu finden. Für Windows ist es eine zip-Datei, weil
    ich gleich noch die nötigen dlls reingepackt habe. Es ist auch
    noch eine alte Version eines Pflichten- und Lastenheftes zu sehen ... ist
    aber schon veraltet ...

    Wenn ich das richtig verstehe ... ist deine GUI nen executable, deine Tools sind auch executables, und die schnittstelle zwischen GUI und tool sind die commando Options sowie cout ??? RIchtig ?

    Nein 🙂 ... aber wenn ich mir das nun so mal durch den Kopf gehen lasse,
    dann finde ich es für eine wirklich gute Idee !!! Bei Veränderungen
    im Quellcode, Updates oder so, müsste ich nur das betreffende Tool
    neu bauen, und zum Download bereitstellen ...
    Aber, wie tausche ich die Daten zwischen den einzelnen ausführbaren
    Dateien aus ??? Ein Teilprogramm liest z.B. die Daten aus
    einem Multimedia-File (Grafik-, Sound- oder Videodatei), und speichert
    diese (bis jetzt) in einer (etwas größeren) Struktur ab.
    Wenn ich nun das nächste "Teilprogramm" aufrufe (Konvertiert ein
    File in ein anderes Format -> z.B. .wmv in .mpg), dann werden
    diese Daten aus der Struktur benötigt. Nur, wie soll ich diese
    Daten dem zweiten Tool zur Verfügung stellen ?? ... auf der
    Kommandozeile ... oder in eine temp-Datei zwischenspeichern ...


Anmelden zum Antworten