(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.
-
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 !?!? :pwas 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" vereinbarenWer 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 ...